探讨用存储过程的优劣

不知，看原版吧。

我个人认为用SP的优点。

1. 投资少。SP在购买数据库时已经支持，不需要企业再投资去购买商业中间件。
2. 速度快，体现在2个方面。预编译的SP比JDBC等送上来的SQL语句要快7倍；减少网络之间数据传递。
3. 复用商业逻辑比中间件强，可以在异构系统中使用，无论是php,.net还是java，均可完美支持。
4. 调优容易。

特别是最后一条我感受最深，公司一大，什么鸟都有，php鸟，java鸟，asp.net鸟，每个部门都有自己的小系统，一些核心数据库以SP开放，可以很好支持这些小系统。

嗯，别人接收你的代码时！

1. 投资少。
真的少吗？存储过程本身如果预编译的话好像要单独购买许可证。
2. 速度快
在整个系统中，某点的速度是否是瓶颈。速度带来的成本是否能被抵消掉是需要认真思考的。动态脚本语言比Java等语言动辄慢几十上百倍。但是做出来的程序很多时候看起来性能并没有什么差距。SP的维护成本和迁移成本高于Java等语言。
3. 复用最强的是SOA。搭建的基础是webservice等松耦合技术，而不是数据库驱动程序。
4.调优容易
调优是系统整体工程。不单单是优化数据库。

个人觉得，对于复杂的、容易经常修改的业务应该放到存储过程里处理。

1是错的。
2,3,4全是废话。

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

2. 速度快，体现在2个方面。预编译的SP比JDBC等送上来的SQL语句要快7倍；减少网络之间数据传递。
----------------------------------
同一句sql放在sp里不会变得更快。sp快最主要的原因是减少了网络调用次数。

感觉楼主的系统是用了N久之前的框架,除了做页面基本不用改什么,把存储过程在配置文件中一设置就OK的那种.项目的环境也很确定,不是互联网应用,最多几百个客户端,并发也不是很多.项目不论怎么发展,客户端也基本是固定,无非就是加一个模块,增加点功能.而且说的不好听一点,很有可能是那种一锤子买卖,项目验收后基本上就啥也不管了.维护的事给钱都不一定管的不管的那种!这样的程序,界面漂亮一点,业务端和数据库只要有一处做的稍好一些就不会出性能问题.也不可能发展到楼上各位所说的那种还需要集群的程度.能把程序和数据库分到两台电脑上都是相当不错的了,多数情况下都是在一台电脑上.

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

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

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

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

4. 你调过吗？


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

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

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