存储过程真的好快!

有点打架的味道了,我也是oracle的知识太少,不了解原理,为什么jdbc里执行的sql,到了存储过程就有质的改变.

上面有人提到的缓存我是不能用的,现在已经有80多万用户了,我用hashmap缓存,jvm要开到1G才稳定

恰恰相反，存储过程中的业务逻辑在后期对于调试和修改甚至于优化都是极为方便的。

不管怎么说，10倍的性能差距已经是足够的理由了。
从我以前的开发经验来说，sql的开发维护不会比java更难，估计这里java程序员更多才会觉得放入java代码更方便。

hehe, 有时候存储过程是好东西拉,  如果是实时计算要求比较高的话, 缓存是搞不定的, 缓存对于网站来将效果不错,  但是对于一些企业应用就不灵了,   另外当不想用ETL工具的时候，还可以用存储过程来替代一下，  总之关键看应用场景，    要做到：以业务为导向，以技术为支撑。

如果是正版付费的大型DB，也就是说将长期使用的话，老老实实写存储过程和sql，千万不要赶时髦搞什么ORM。

几天没见。居然这么大的反应。看到自己的话被大家反复打压，心里真不是滋味。在下也写过一些存储过程。说真的，很难调。也许是我数据库水平太差加不会用开发工具吧，根本不能做什么单元测试、集成测试之类的。只能自己准备测试数据，跑程序，中间自己加print语句输出看是否执行到那里。出的错误也很难搞清楚是哪里的问题。
不过无论如何，我也不会同意Java在处理业务上不如SQL。现在的设计发展趋势均是以对象和领域模型为核心，数据库的关系模型已经退居二线。在表示复杂模型上，ER图很难表示出来。就是表示出来了，理解起来也很费劲。
当然，如果你对象设计功底不到，就觉得存储过程比对象好了。

java写的逻辑 最后不是到数据里执行的么？

同意你的观点，其实sql就是 数据领域的dsl语言嘛，要好好掌握，指望orm是不行的。
plsql developer开发调试存储过程完全没有问题，pl/sql也有unit test包
数据库的关系模型退居二线啦?这个真是初次听说

我现在就比较头痛，接收的项目里面有块重要的业务逻辑的是用存储过程写的，现在改点东西，都得找DBA改，然后再联调

暂且不谈开发效率、维护性的问题，业务逻辑用存储过程来实现最大的危害在于，你没有办法进行群集扩展！

金融和电信行业的确在数据库服务器的硬件投资少不会吝惜，但是数据库服务器是单点的，极难扩展，即便Oracle的群集，他的共享存储数据库也是单点的，如果业务逻辑的运算非常消耗CPU和IO，你没有任何有效的办法来扩展系统的性能。

对于并非极度依赖数据的业务逻辑运算，如果在应用服务器端来实现的话，特别是采用SNA架构的情况下，理论上可以获得无限的水平扩展能力，只要加服务器就行了。但如果你放在数据库里面，你就大眼瞪小眼了，加服务器都不管用了。

对于那些对于性能要求极度苛刻的大负载应用，比方说阿里巴巴，拥有中国最强的Oracle DBA团队，已经把Oracle的配置优化到极限，已经把SQL优化到极限了。他们绝对不允许程序员把业务逻辑写成存储过程，甚至不允许程序员创建触发器、不允许程序员创建表的外键约束，外键关系自己在程序里面维护。凡是能够在应用层进行检查的工作绝不能放在数据库层，加重数据库服务器的负担。

我只希望大家记住一点：数据库服务器出现CPU和IO瓶颈，你没有办法扩展，但是应用服务器出现CPU和IO瓶颈，你只需要加服务器就行了。