探讨用存储过程的优劣

这才是大实话啊。把Oracle当MySQL用，还真是把钱不当钱啊！

不过话又说回来，在国内的一些小公司的小系统，换数据库是家常便饭，所以Hibernate才会这么爽——因为换数据库不需要改大量代码。

1. 你到说说你哪个数据库需要预编译购买许可证？你自己都不确定能当成论据吗？

2. 兔子和兔子比，才能说是世界上跑得最快的兔子。兔子和乌龟比，能说是世界上那个跑得最快的兔子么。你这种论调就是让兔子和乌龟去比。JDBC（或者其他什么机车）送上100句SQL以便做出个表格永远就是比这100句SQL写入SP慢，这才是兔子和兔子比。性能的提升就意味着更少的投资。至于所谓的维护成本和迁移成本，就有点臆测的味道了。

3. SOA强虽强，却是性能低下的方案，而且还需要额外的投资。假如SP就可以胜任，为什么要用只笨乌龟来担当呢？

SOA暴露的只是接口，其商业逻辑还是可以存在SP，SOA作为SP的一种Client而已。例如银行的日报、月报、季度报、年报这种动则要存取上百个表的逻辑，SOA能搞得定吗？还不是交给后台的SP来处理。

4. 你调过吗？


基本上你说的意见就是上面那位同学说的： 1是错的，2，3，4全是废话。

动态脚本语言以及规则引擎才是归宿。

说说存储过程的缺点吧：
1.运维复杂，业务变化导致的存储过程变化太难受，个人的切身体会，特别是存储过程长的时候：一.可读性太差，如果中间被人改个两三次，就更难受了，如果涉及到三、四个表，不懂业务的就很难读懂了；二.可复用性差，这是过程代码的典型劣势，不是说它没有复用性，但它的复用性和面向对象比起来是差一大截的；三.可维护性差，版本控制很难搞，不像代码环境能集成版本控制软件；且主、备和开发环境的不能随时同步。
2.不能使用对象缓存，也就是说客户请求除了少部分通过客户端缓存和页面缓存，大部分请求都直接捅到数据库了，浪费了利用应用服务器资源的机会。

1 DB2的部分版本是需要C编译器编译存储过程的。这个C编译器要花钱购买或者使用免费的GCC。而且有时候SQL运行速度不够，其中一个解决办法就是用C、Java等语言开发存储过程。编译后在数据库中运行。这个功能有的数据库是需要额外花钱的。
2.应用缓存可以极大缓解数据库IO压力。我从内存里拿总比你从远程IO取快。只要设计合理，缓存的命中率还是非常高的。
3.你直接把数据库放公网提供SP服务试试去。报表什么的是数据仓库、智能BI的事情，关SOA什么事情。
4.别用这种腔调说话。