JEE中实用存储过程的合适场景（讨论贴）

Java社区有一种根深蒂固的观点：业务逻辑最好全部用java来写，存储过程不用或者少用。

这种观点真的正确么？
昨天读《J2EE WHITOUT EJB》，Rod Johnson提到：他认为这样是错误的，存储过程在数据库关系操作等类似的操作中，具有优势；业务逻辑还是应该用java来写。。。。

但是他那一段我反复读了三四遍，都没搞明白：什么是关系操作，什么是业务逻辑?

发这个帖子，希望大家来探讨一下在JEE项目中使用和不适用存储过程的合适的场景？

我先说几个场景

1，更新了某表的一个字段，另外一个表的都要响应的更新。如果用触发器和存储过程，性能是要好一点的。（这种表之间的关联互动关系，是Johnson说的“关系操作”么？知道类似的场景的请列举）
2，业务相对稳定，对性能要求很高，用存储过程（比如电信计费）
3，批量处理，分析处理逻辑可以考虑存储过程。

4，不实用存储过程的场景，这个是网上搜到某人的经验：存储过程执行时间过长，导致前台没反应，将一部分逻辑移交到前台，从而使得总执行时间增加，但是响应时间减少。

5，

:这个不同于johnson的划分是存储逻辑和业务逻辑
参见其解释

前几天读oracle 9i&10g编程艺术这本书，作者就提倡业务逻辑用stored procedure来完成。理由的既然花钱买了oracle这种数据库，就应该充分使用数据库的功能。

我不太敢苟同这种看法。作者因为是oracle公司的，无论开发什么应用，必然使用oracle数据库。而且又是oracle专家，当然用存储过程游刃有余，又不会面对数据库移植性的问题。

但对大部分企业应用来说，数据库未必是一成不变的，有时候甚至要服从客户的决定。如果系统大部分的业务逻辑用pl/sql来写，一旦客户要求用sql server，总不能把整个系统用transact-sql再写一遍吧。而且大量使用存储过程，会导致代码难以管理，特别是当你的程序员并不十分了解数据库的内部原理的时候。这样都会导致开发成本的增加。

对我来说，我只考虑哪些需要实时数据，客户对响应时间要求较高，而又牵涉的大量数据的场景，才会使用存储过程。其他的，还是用java好了。

你的讨论贴发在海版，没有人来讨论啊。

大部分企业应用,数据库恰恰是一成不变的.... 要变顶多从oralce 7i 升级到 8i (这已经是惊天动地的大事了,起码要各业务核算一周数据).


储存过程好处:

1. 适合监管,适合调用 --- 通过存储过程暴露业务过程,适合异构平台重用业务逻辑,这在企业开发中也很普遍,需要从许多数据库汇总业务数据, 每个业务数据库暴露出其可用的存储过程,远比暴露出表结构强. 举个例子: QA部门的客服数据是java 系统, 物料部门的BOM是cobol, 你如何去查询每种物料的故障率??? 这种在业务发展中不段出现的跨数据库查询, 用存储过程是个相当不错的方法,远比web service好用



2. 性能比在中间层快,适合调优 --- 尤其是在长时间的报表汇总中, 存储过程调优远比什么ejb,hibernate强悍,可用工具也多.

3. 大数据量汇总,中间件根本无法胜任.

                  存储过程                      中间件
数据库迁移             难                            易
编写生产率             低                            高
调优能力               强                            弱
逻辑重用               异构平台,强                   异构平台,弱
大数据汇总             易                            难
性能                   高                            低
触发约束机制           强                            弱

完全同意楼上的看法。只能说，没有最好，只有最适合。

在数据库不变的前提下，存储过程几乎唯一的缺点就是编写生产率。但这恰恰是对软件公司开发成本很重要的一个因素。我们不能只为了提高了软件运行的效率，而降低了自己开发的效率。

存储过程需要对数据库原理有较深的理解。否则一个错误的锁定或者一个错误的索引，就可能让所有性能提高化为乌有。你能保证你公司的程序员同时又都是数据库高手吗？

所以，我仍然坚持，对于中小型企业系统，我只考虑哪些需要实时数据，客户对响应时间要求较高，而又牵涉的大量数据的场景，才会使用存储过程。其他的，还是用java好了。

一般小型系统更乐意采用中间件吧,大型系统无一得全部或者部分采用存储过程......唯一是存储过程好手太少,你能成为一把好手,肯定比java得吃香.

存储过程是提高了开发效率，而不是你说的降低．
另外，你说的那些问题，如果你的程序员在存储过程中处理不好的事情，那么他在Java里也一样处理不好．

企业完全可以下一个定量的定义，比如

                    存储过程                      中间件
数据库迁移             难                            易
编写生产率             低                            高
调优能力               强                            弱
逻辑重用               异构平台,强                   异构平台,弱
大数据汇总             易                            难
性能                   高                            低
触发约束机制           强                            弱

这个总结很经典，但是还需要量化，比如性能高，系统需要多高的性能才迫使你使用存储过程，是因为要求某个运算响应在2秒之内，用java写实现不了？是因为某个操作反复从数据库取值，数据传输消耗的时间远远大于运算的时间？我相信一个系统不可能所有业务全放在数据库上，需要放在上面的业务和全部业务比，总归是少数。

我们是这么做的．简单的存储,查询是在Java里的，但复杂的业务逻辑全部用pl/sql.这样做可以节省大量的代码量．而且pl/sql的调试特别方便．这是多年下来的实际工程经验，

就我所知，我们行业内部，大部分的金融，保险，证券的行业软件都是这样做的．这些软件都较大型，专业（业务逻辑极复杂），经得起时间考验的．不是那种政府网站之类的简单应用．