|
分页查询是经常能够碰到的问题，我们首先看看分页查询存在的理由: - 方便用户：用户不可能一次察看所有数据，所以一页一页的翻看比较好。
- 提高性能：一次从数据库中提取所有数据会比较慢。
那么现在我来尝试反驳上述理由： - 真的方便吗？我们考虑下面的情况
- 假如数据只有20条。
- 假如数据超过1000条。
第一种显然不必分页查询。希奇的是第二种也不必，因为没有哪个用户愿意一页一页的翻到最后，假如用户查询到的数据超过了他所关心的数据范围，我认为应该让他重新输入查询条件，就像我们使用google一样。
但是作为一个友好的应用界面，我们总是希望用户可以全面的了解他的查询结果，所以有必要告诉用户：“你查到了多少数据，但是，目前只能显示前1000条，假如您希望察看所有数据，那么应该如何如何... ”
- 性能会提高吗？
- 假如数据量很小，显然性能不会有明显的提升，相反，性能会大大下降。因为数据库执行了不必要的查询和查询条件。
- 假如数据量很大，性能也不见得有明显提升，因为你总是要执行一个额外的count查询，并且，组合SQL的时候极有可能造成全表扫描。当然这要看数据库的实现原理了。
- 可以想像，分页查询对于性能的影响和数据量之间的关系应该是一个曲线，数据量小的时候会降低性能，数据量大的时候可能（根据不同的数据库）会提升性能。要害是通过测试，找到曲线的拐点。性能不是根据经验和感觉得到的，而是通过测试得到的
- 另外，假如一次全部取出数据，的确会造成空间性能的影响，但是，现在内存很便宜...
- 负面影响
- 对于一个架构良好的web应用，将pageNo和PageSize在各个类之间传递实在是不爽，这两个数据明显属于表现层。当然，假如你使用RoR算俺没说。
- 明显提高编程复杂度，尤其是在考虑数据库无关性的时候。
- 希奇的现象：为什么没有一个大型数据库直接提供分页查询？Oracle的RowNo不是用于分页的，SQLServer的Top更不是。
- 结论
- ExtremeTable、DisplayTag、JSF DataTable都提供了简单的分页方式，那就是在结果集合中分页。使用非常方便，而且使得逻辑清楚，大大提高了工作效率。绝大多数情况下，可以直接使用这种方式。
- 假如通过测试，发现上述方式影响了性能，那么考虑使用分页查询。
- 对于用户量很大的应用，因为内存的原因，也可以考虑分页查询。但是，我个人更推荐缓存方式：同样的查询放在一个缓存中...
- 采用合理的设计，屏蔽开发人员处理分页逻辑。比如，将分页逻辑和count查询放在父类，开发人员负责组合查询条件。具体看设计模式吧。
欢迎大家讨论！！！
Root decorator: all decisions about how a page is to be decorated via the
inline decoration begins here.
Switch based upon the context. However, for now, just delegate to a decorator
identified directly by the context.
|
| 共2页: 上一页 1 [2] 下一页 |
评论加载中…
