存储过程真的好快!

文档和注释写得好，同时开发人员呱呱叫，SP同样可以做得和语言一样好。不要一棒子打死

用不用存储过程，主要从网络传输和性能方面考虑。
数据库移值不用考虑这些了（谁没事总移来移去的，再说存储过程的重写没有想的那样恐怖）。
把存储过程用在适合使用的地方！

最近在看thomas kyte的oracle10g的书。他是倾向业务写在存储过程的。
而我之前看的一些java高手写的书，都是倾向于业务写在java代码中的。
thomas是高手吗？当然是。
spring的作者是高手吗？当然也是。
为撒他们的一些经验之谈有如此大的反差呢？

bluemeteor的话我觉得最中肯。这个关键是要看你的团队的技术实力了。
如果作为系统设计者最好能数据库和语言方面都深入了解，才能选择相对比较优化的方案。

恰恰相反，对修改特别方便！特别是以后部署后想修改。

调试成本跟jdbc 直接调用sql没区别。

oracle 的很多工具可以支持存储过程断点调试
数据库跨平台？可能是我工作的年头少，6年来还没见过，而且越是大项目越是数据库平台绑定的。
如果考虑数据库跨平台可以考虑多版本数据库sql实现的方法
至于代码容易混乱的问题和sql没关系。这个是人的问题，用Java一样能写的乱
thomas kyte 的那本oracle体系结构 建议搞Java的人也看看。

呵呵，这是一场口水仗

我还是认为做多版本sql要比把所有业务写在java中好
thomas kyte 的那本中说过同一套sql到不同数据库上执行可能会得到不同结果，这个问题就是大问题了。
www.open-open.com上面有几个开源的ERP、CRM系统都是采用多版本sql实现的方式。

做项目和做产品是不一样的。产品通用性要强得多，可以要你for oracle,for sybase，for    db等。对项目就要求少得多。而且一个项目交接后基本上很少存在要去换数据库的。用存储过程。有时候还就是为了修改业务方便。我们就是因为业务多变把很多业务写到存储过程。这总比隔两天改程序重新部署强。当然缺点也不少。就像所说的非面向对象，调试不方便等。总的来说用或不用，怎么用看场景平衡吧

是的，他们的做法是提供好几套数据库脚本、存储过程、自定义函数等

恩
thomas kyte的那本书有比较详细的阐述，即使是所谓的标准SQL，不同的数据的具体实现细节也有很大的不同。一些你在SQLSERVER执行的很好的SQL跑到ORACLE上会出现你难以想象的问题。
实际操作中，想一套SQL直接跨数据库，基本是不太可能的事。
既然想一套SQL跨数据库不可能，那么把业务放在存储过程中也是可以接受的。。

对于thomas kyte的理论，我没有实际的操作经验，毕竟我的oracle水平实在是菜。让我把业务放到SQL储存过程中还没有哪个胆子。不过很希望能看到这个帖子的回覆里面能有把业务核心都放到存储过程中实施，并且起到优良效果的大大出来介绍下自己的经验。

老兄有相关的经验不？最近我们的项目中遇到很多oracle的问题，因为项目里面没有oracle牛的DBA，一些东西搞得我很痛苦。开始狂补oracle了。开发人员不了解数据库还是不行啊。哎