技术选型带来的困扰

以我的经验谈谈我的个人看法:
1、首先，积累了30年的数据库数据量想必大得惊人。如果你的应用需要频繁的查询数千万的数据，那么必须在适当的地方采用存储过程来表现业务逻辑，尽量利用数据库自身的能力来完成复合的数据查找、比较和筛选。商用数据库本身在这方面的处理是非常强劲而稳定的。其数据处理能力是Java虚拟机所无法比拟的（无论你用任何框架，写出任何出色的代码）。
2、尽量保持由存储过程处理完毕后的数据量在较小的范围内，缩减到“数万”这个级别，然后再交给Java虚拟机来完成其他的业务逻辑。
3、你觉得参杂了存储过程会让你们的代码不够OO，但这样的程序稳定性会高出许多。
4、完全采用Hibernate这种小玩意儿来做海量规模的数据处理绝对是下下策，我见过的所有完全采用Hibernate的电信级计费系统无一例外都是失败案例。至少在可靠性和鲁棒性上极其脆弱。我所经历的基于存储过程的案例几乎都是非常成功的。
5、我不是说Hibernate不好，事实上它在做Web应用中非常非常出色。但不适合将所有的数据逻辑都交给它。把很“搞人脑袋”的逻辑交给Hibernate,把很“搞CPU”的交给存储过程。
6、使用Hibernate的时候，切忌此类简单用法：将要处理的数据全部从数据库中以Active状态捞到JVM，指望让JVM来完成所有工作。有时候，你一不小心，就会这么做。
7、方案，存储过程+Hibernate

个人看法。

1、如果原来有存储过程，就善加利用，如果没有说明这个系统数据量不够真正的大。
2、业务需求不明，即使超过万仍然是有办法的，但是需求要给出才能评估。
3、OO和稳定性没有矛盾之处，存储过程一样容易出bug。OO的代码不稳定也是一种bug，没有本质区别。
4、Hibernate是小玩意儿，那是你不知道使用技巧，适用范围不是看数据量大小的，是要看需求的，比如是否需要实时生成新的表。
5、Hibernate要用得好，sql一定也很好，不可能完全交给Hibernate的，必须要清楚任何状态下生成的sql的大致形态。
6、其他框架也有类似问题，只是不那么容易内存溢出而已，其实是数据结构的基础问题。
7、可以考虑，如果原来没有存储过程的话，需求中又有类似电信计费这种，你又熟悉存储过程的话，建议如此。