存储过程真的好快!

有点疑惑，如果把大量的业务逻辑放到webserver来处理，那么webserver和dbserver之间数据的传输量肯定会比把业务放到dbserver进行处理，然后dbserver只返回少量处理后的数据多。
当访问量大规模提高之后，webserver和dbserver这种传输的消耗肯定也要打规模提高。这个地方如果出现瓶颈是能用添加服务器来解决的？

java处理业务肯定不如SQL，PL/SQL可以一句顶一万句，JAVA里面好多都是废话，比如jdbc里面的什么准备statment啊之类的。

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

robbin 你能给出一个具体的数字么？究竟提高到什么程度？

当然JavaEye这类网站这类的应用，我是同意的观点。
   我想这个帖子是在业务系统为主的前提下
      

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

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

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

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

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

比方说我2005年给X行咨询的一个关于全行票据交易的项目，很繁重的业务运算，一开始跑的还挺快，但上了十几个省的分行以后，一个WebSphere顶不住了，繁忙的时候页面响应很慢，几乎出不来了。于是我们做了水平和垂直群集，两台HP9000的小型机跑应用服务器，每台小型机上面跑两个WebSphere实例，做垂直群集，小型机之间再做水平群集。总共是4个WebSphere实例的群集，这下业务系统就恢复了正常。等全国30省的所有分行全部开放以后，每天还是跑得稳稳的。如果业务量再大，还可以继续添加服务器和WebSphere实例。如果你都把业务放在数据库里面实现，我看你怎么扩展数据库和硬件？

2.设放在pl/sql里的都是那种极度依赖数据的业务逻辑（我们公司就是这样）。
来来回回的找表运算，来来回回，运算。
这种运算。你从PL/SQL中抽出，现在放到应用端来做。
好，过了一年，发现数据量大了，速度不够用了。
这个时候你加应用服务器有用吗？没有用，加再多都不行。
因为真正的耗时最终还是被传递到DB上面。你只能加强，优化DB。没有别的办法。

WebSphere集群主要解决的是什么问题？和存储过程有关系么？


web集群、中间件集群、数据库集群每个层面都有自己主要解决的领域

因为真正的耗时最终还是被传递到DB上面。你只能加强，优化DB。没有别的办法。