如何处理来自数据库的巨大结果集

Question

我正在设计一个多层数据库驱动的Web应用程序 - SQL关系数据库,用于中间服务层的Java,用于UI的Web.这种语言并不重要.

中间服务层执行数据库的实际查询.用户界面只是询问某些数据,并没有任何数据库支持的概念.

问题是如何处理大型数据集？用户界面要求提供数据,但结果可能很大,可能太大而无法容纳在内存中.例如,街道标志应用程序可能具有以下服务层:

StreetSign getStreetSign(int identifier)
Collection<StreetSign> getStreetSigns(Street street)
Collection<StreetSign> getStreetSigns(LatLonBox box)

UI层要求使所有街道标志符合某些标准.根据标准,结果集可能很大.UI层可能会将结果划分为单独的页面(对于浏览器)或只是将它们全部呈现(为Goolge Earth提供服务).潜在的巨大结果集可能是性能和资源问题(内存不足).

一种解决方案是不返回完全加载的对象(StreetSign对象).而是返回某种结果集或迭代器,它们懒洋洋地加载每个单独的对象.

另一种解决方案是更改服务API以返回所请求数据的子集:

Collection<StreetSign> getStreetSigns(LatLonBox box, int pageNumber, int resultsPerPage)

当然,UI仍然可以请求一个巨大的结果集:

getStreetSigns(box, 1, 1000000000)

我很好奇这个场景的标准行业设计模式是什么？

Answer 1

第一个问题应该是:

¿用户需要或能够管理这么多数据？

虽然结果集应该被分页,但如果它的潜在大小如此巨大,答案将"可能不是",因此UI不应该尝试显示它.

我从事医疗保健系统的J2EE项目,处理大量的存储数据,数百万患者,访问,表格等,一般规则是不要为任何用户搜索显示超过100或200行,建议用户,这些标准产生了他能理解的更多信息.

实现此方法的方式因项目而异,可以强制UI在启动之前向服务层询问查询的大小,或者如果结果集增长,则可以从服务层抛出异常太多(但是这种方式将服务层与UI的有限实现相结合).

小心!这并不意味着服务层上的每个方法如果其结果大小超过100就必须抛出异常,这个一般规则仅适用于直接向用户显示的结果集,这是将控件放在UI中的更好理由而是在服务层上.

Answer 2

在 ASP.NET 中，我将使用服务器端分页，您只检索用户从数据存储中请求的数据页。这与检索整个结果集、将其放入内存并根据请求对其进行分页相反。