ASP中关于分页查询和功能成绩

ASP中关于分页查询和功能成绩

　　分页查询是常常可以遇到的成绩，咱们首先看看分页查询存在的理由:
　　
　　方便用户：用户不能够一次察看一切数据，所以一页一页的翻看比较好。
　　
　　提高功能：一次从数据库中提取一切数据会比较慢。
　　
　　那么如今我来尝试反驳上述理由：
　　
　　真的方便吗？咱们思考下面的情况
　　
　　假设数据只要20条。
　　
　　假设数据超过1000条。
　　
　　第一种显然不必分页查询。奇异的是第二种也不必，由于没有哪个用户情愿一页一页的翻到最后，假设用户查询到的数据超过了他所关怀的数据范围，我以为应该让他重新输入查询条件，就像咱们利用google一样。
　　
　　然而作为一个敌对的运用界面，咱们总是宿愿用户可能片面的了解他的查询后果，所以有必要通知用户：“你查到了多多数据，然而，目前只能显示前1000条，假设您宿愿察看一切数据，那么应该如何如何...”
　　
　　功能会提高吗？
　　
　　假设数据量很小，显然功能不会有显著的降职，雷同，功能会大大降落。由于数据库执行了不必要的查询和查询条件。
　　
　　假设数据量很大，功能也不见得有显著降职，由于你总是要执行一个额外的count查询，并且，组合SQL的时分极有能够形成全表扫描。当然这要看数据库的完成原理了。
　　
　　可能想像，分页查询对于功能的影响和数据量之间的关系应该是一个曲线，数据量小的时分会升高功能，数据量大的时分能够（依据不同的数据库）会降职功能。要害是经过测试，找到曲线的拐点。功能不是依据阅历和感觉失去的，而是经过测试失去的
　　
　　另外，假设一次全副取出数据，确实会形成空间功能的影响，然而，如今内存很便宜...
　　
　　负面影响
　　
　　对于一个架构良好的web运用，将pageNo和PageSize在各个类之间传递真实是不爽，这两个数据显著属于体现层。当然，假设你利用RoR算俺没说。
　　
　　显著提高编程简单度，尤其是在思考数据库有关性的时分。
　　
　　奇异的现象：为什么没有一个大型数据库间接提供分页查询？Oracle的RowNo不是用于分页的，SQLServer的Top更不是。
　　
　　论断
　　
　　ExtremeTable、DisplayTag、JSFDataTable都提供了简略的分页模式，那就是在后果汇合中分页。利用十分方便，而且使得逻辑明晰，大大提高了工作效率。绝大少数情况下，可能间接利用这种模式。
　　
　　假设经过测试，发现上述模式影响了功能，那么思考利用分页查询。
　　
　　对于用户量很大的运用，由于内存的缘由，也可能思考分页查询。然而，我集体更引荐缓存模式：异样的查询放在一个缓存中...
　　
　　采用正当的设计，屏蔽开发人员解决分页逻辑。比如，将分页逻辑和count查询放在父类，开发人员担任组合查询条件。详细看设计形式吧。