存储过程真的好快!

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

金融和电信行业的确在数据库服务器的硬件投资少不会吝惜，但是数据库服务器是单点的，极难扩展，即便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。没有别的办法。

首先，你所说的存储过程调试不方便是不存在的。在用对了工具时，存储过程的调试对于数据库应用来说，比其他语言都更为方便。用一下PL/SQL Developer试一下。

第二：A客户要用Oracle,B客户要用sybase的问题。很好解决，我们只提供Oracle版本的产品。就算是和IBM合作，也没有使用DB2。Oracle就是比其他数据库好，没有办法。当然Oracle也是最贵的，但是对于大型项目来说，我们的客户不会在乎数据库的价格。这是他必须要付出的。

第三：关于存储过程维护难的问题，更是可笑。我们的核心计算几乎全部是PL/SQL写出来的。经常会有写得极好的成千上万行的PL/SQL存在。而对于Java来说，我觉得面像对象的东西，很多个Class写在那儿，可真正专注于计算的，也就是几行。大多数Java没有在计算，但Java可以用来搭出很好的架子来。我们公司的做法就是Java搭架子 + PL/SQL的核心计算。极好。关于这个做法，就我所知，在真正需要强大计算的金融保险行业极为流行。这是实践出来的东西。

也许那些只是简单的CRUD的应用，才会觉得PL/SQL没什么用。

后头有你叫的时候。大量业务写入存储过程，对调试和修改均极为不方便。我觉得你这种业务用缓存的方式解决最好。处理一次，缓存起来。没了查询数据库，不是更快。等缓存失效了，才需要二次运算。缓存时限可以根据你的需求定，哪怕有1分钟，对高并发的访问都是可以大大缓解的。