探讨用存储过程的优劣

我说一句，for update跟你用不用存储过程一毛钱关系也没用。
这是业务决定的，不是说跟你用的jdbc,ibatis,hibernate,pl/sql决定的。

所谓企业应用 高并发 其实这种场景极少。

业务既复杂，触发频度又要高。这种不是简单用存储过程或者是用什么语言去解决的。更多是要考虑怎么设计这个架构了

企业应用一般都是低并发，而且很难真正cache住数据。
互联网应用是高并发，有大量数据可以做cache。

区别还是相当明显的。

我也有好几年在和DB2的存储过程打交道，应用系统中把业务封装在SP中确实是个很不错的方法，系统能够很好地维护，扩展，修改。 

我们那个系统，九十年代末就在开发使用了，边开发边用，一直沿用到现在，前面应用程序都换了好多个版本了，从Lotus， PHP 到现在的java，java也是五花八门，有jsp，struct，JSF，Extjs啥都有，由于业务逻辑都在存储过程里面，即使经手了那么多人，仍然没有烂掉。

另外在复杂的应用系统里面，让DB开发人员来写SQL，比程序员来写要好很多。做好复杂的应用对于程序员来说，既要懂业务，懂开发，同时还要深入理解SQL才能开发出高效的模块。而对于DB Engineer来说，懂业务和SQL就可以。


这里说的复杂的应用，是指那种一个按钮下去，访问了十几个表，执行十几条SQL的应用。一般来说，这种情形下，缓存几本没用，只是一个负担而已，因为其中任何一个表改变了信息，缓存就得失效。

应该是这样，所以我估计用类似oracle而不是类似mysql这样的数据库会更好些。对执行速度要求很高的场合当然还是用存储过程好些，否则还是用高级语言更好。