谢谢分享经验,我n年以前用ASP写MIS的时候也碰到了这样的情况,拼命做分页程序,几乎通宵,结果第二天,用的人还说数据太多没什么用,当时的心情别说又有挫折了.不过回过来想想,也是自己的错觉,觉的技术是解决问题的唯一途径,实际上搞清楚用户需要什么才是最最重要的,当然如果技术障碍是用户需求的关键那对我是最好玩的.
说到底,还是喜欢这种感觉,钻研技术的感觉.
================================================================
谈一个我自己的经历，也就是上个星期的事。
上星期做的一个东东是基于 LDAP 的员工查询系统。几个月前我实现了这个模块，但是当时的实现是每次查询都要与 LDAP 做通讯，取出所有符合查询条件的记录，然后做分页计算，显示后就将记录集丢掉。一旦分页，又要做相同的操作。从这个实现上来看，效率是很低的。只是因为 LDAP 中员工的数据量有限(也就几K)，而且我们使用的服务器的性能还算不错，查询本地员工的效率(1K 左右)就没有什么明显的停滞，用户也没有什么抱怨，于是我没有做什么优化。
但是近来，我开始用这个东东查询其它分公司的员工，发现在对整个 LDAP Tree 做查询时，效率非常低。而且服务器有限制，最多一次只能返回 2k 条数据。于是我开始想着怎么做优化。一开始我并没有看清楚自己应用的情况。我的应用其实分为两个部分，一个是查询，另一个是将 LDAP 中的数据全部导出。我当时认为无论是查询还是导出数据，它们的应用都是一样的，都是将满足某个条件的结果集列出，只是一个是分页显示，一个是全部列出。于是在做查询时，我也将满足要求的记录全数拿出做分页。这一次我做了 cache，对相同查询条件的结果集做了cache，做分页时的效率要比以前高，后来我想，从 LDAP 中取数据老是要经过网络，性能受限，对于大的结果集，传输量太大，于是我用 Lucene 做了一个 Index，每隔一段时间就在后台用 Thread 做 Index，同步两边的数居，在本地进行查询和处理的效率应该比经过网络要好。但是后来我很快就发现分页显示的查询应用是不需要返回一个大的结果集的，一方面用户做 pagination 操作时会很烦，而且这么大的数据量往往是无效信息过多，对用户毫无意义。另一方面出于对公司员工信息的保护，也不应该提供如此"便利"的功能，LDAP 服务器上2K条记录的限制是有意义的。
最后我还是取消了 Index 的功能，对于查询，我恢复成从网络取数据。一方面是这样的数据及时，第二个方面服务器之间可以走千兆网，效率不会比本地低多少。另外经过 cache 处理，尽管第一次查询效率慢，但是分页时的效率就很好了。最后就是不鼓励用户对大的数据量进行查询，如果可以选择，我宁愿把大数据量的查询做得更慢。
对于全部员工信息导出的功能，这是个受限功能，只有授权的人才能使用。这有一个经验可以分享一下，LDAP 中的 PagedResultsControl 可以用来获取所有的数据。
注: LDAP 有 VLV 扩展协议，但是因为我们的服务器不支持这种协议，所以我需要自己做分页计算。
这一次走了不少弯路，连 Index 我都已经实现了，最后才发现这样的功能不符合要求。做了不少的无用功。
总的来说，动手前应该先做设计，即使是在纸上简单的画一画，也可以使自己冷静下来，好好想想自己到底想要什么。