我们在网上也可以看到很多关于高性能分页的方法，就是所谓的，Grid上显示时，只读取相应页的数据，每次分页提交，重新读取从第n条开始的共m条记录来提高访问的性能。
这种方法可以减少Client与Server之间的传递数据，可以从一定意义上提高页面速度，但实现起来都是会比较麻烦一点：
1）页面上的Grid不能直接使用绑定功能，需要先访问数据库读取Count(*)条数，然后对Grid进行页数计算。
2）无法使用Grid自带的分页功能，不管是MS的还是第三方的，都要求手写分页代码
3）在界面上提供“显示每页n条”的功能的话，客户修改此N值时，系统就要重新统计Count等。
在网上有个专门的存储过程，用于返回第N到M的记录，里面使用的是两次TOP方法，不知道这样的语句，速度怎么样？
而我的个有观点：
采用黙认的方式，虽然系统一次载入数据会多一点，但目前的硬件设备发展很快，可以弥补一部分，而且在界面上，可以充分使用Grid的功能，开发相当方便。
而且系统其实没有那个必要返回所谓的几万条，这样的记录数进行分页，首先是个不太现实的，估计很少有人会翻上几千页吧。因此，我感觉，对于客户来说，大数据量的返回，本身是没有多大意义的，而应该从前N条来考虑，就算是大数据量，我们也没有必要返回那么多，只要前N条就够受的了，如果实在要显示多的话，也可以使用分批载入的功能，比如先载入n条，客户发现数据太少，进行再载入n条。对于数据量很大的，应该建议客户进行数据查询，以减少数据量的返回。
因此，在我的思想中，我一直是觉得，在Web上本身就没有必要显示大数据量的必要性，而且我还非常不建议进行分页显示，分页显示有时是非常不方便的。比如要进行一些数据的统计等。应该提倡组合查询与前N条的分批载入。
如果只是几百条，我还是提倡不分页，让客户在页面上能看到所有的，要比一页页往下翻方便多了。
因此，我一直在思考，到底是否应该使用高性能分页？？有这样的必要吗？我担心为了追求不是那么必要的性能，而放弃的更多。
希望大家讨论讨论。我也是忧郁不定啊。
补：思考的原因是想：要不要在SPL中添加这样的数据段返回功能？？有没有必要性？
这种方法可以减少Client与Server之间的传递数据，可以从一定意义上提高页面速度，但实现起来都是会比较麻烦一点：
1）页面上的Grid不能直接使用绑定功能，需要先访问数据库读取Count(*)条数，然后对Grid进行页数计算。
2）无法使用Grid自带的分页功能，不管是MS的还是第三方的，都要求手写分页代码
3）在界面上提供“显示每页n条”的功能的话，客户修改此N值时，系统就要重新统计Count等。
在网上有个专门的存储过程，用于返回第N到M的记录，里面使用的是两次TOP方法，不知道这样的语句，速度怎么样？
而我的个有观点：
采用黙认的方式，虽然系统一次载入数据会多一点，但目前的硬件设备发展很快，可以弥补一部分，而且在界面上，可以充分使用Grid的功能，开发相当方便。
而且系统其实没有那个必要返回所谓的几万条，这样的记录数进行分页，首先是个不太现实的，估计很少有人会翻上几千页吧。因此，我感觉，对于客户来说，大数据量的返回，本身是没有多大意义的，而应该从前N条来考虑，就算是大数据量，我们也没有必要返回那么多，只要前N条就够受的了，如果实在要显示多的话，也可以使用分批载入的功能，比如先载入n条，客户发现数据太少，进行再载入n条。对于数据量很大的，应该建议客户进行数据查询，以减少数据量的返回。
因此，在我的思想中，我一直是觉得，在Web上本身就没有必要显示大数据量的必要性，而且我还非常不建议进行分页显示，分页显示有时是非常不方便的。比如要进行一些数据的统计等。应该提倡组合查询与前N条的分批载入。
如果只是几百条，我还是提倡不分页，让客户在页面上能看到所有的，要比一页页往下翻方便多了。
因此，我一直在思考，到底是否应该使用高性能分页？？有这样的必要吗？我担心为了追求不是那么必要的性能，而放弃的更多。
希望大家讨论讨论。我也是忧郁不定啊。
补：思考的原因是想：要不要在SPL中添加这样的数据段返回功能？？有没有必要性？
