各位老大：在EJB开发中，直接使用存储过程好还是使用CMP调用数据库好？

Question

用Stored Proc的好处是可以给非EJB应用程序调用。至于快不快我不知道，你测试好了，然后告诉大家。我觉得Java很多东西是以牺牲速度来换取系统扩展性和移植性的。
把企业逻辑放在Stored Proc里是不是破坏了系统结构，加大了数据库与企业逻辑的偶合性，从而使得系统的移植性降低?另外，很多人说过度地把企业逻辑放在Stored Proc反而会降低整体系统的性能，数据库这种瓶颈在系统中是越少碰越好，大量的Stored Proc会加重数据库的负担，使这个瓶颈越来越窄，影响系统整体性能。

Answer 1

补充: 系统的企业逻辑被放在两个不同的地方---EJB和Stored Procedure，这样增加了系统维护的难度。好处是:
1、处理大量数据密集型操作时，Stored Proc能减少网络上的交互，因此提高了性能；
2、对那些非EJB的应用程序，Stored Proc提供了实施企业逻辑的空间

Answer 2

不用cmp,程序移植会有问题..每个数据库的存储过程不一样吧 ? (我不太清楚)
如果你开发用sqlserver,而以后又用orical,怎么办?

Answer 3

每个数据库的存储过程都不一样，oracle的过程不能直接放到sql里用。
因此在数据库不移植的情况下你的问题才有意义。前提：数据库不移植
使用store p使得数据存取逻辑出现的位置分散，系统封装性破坏，且维护困难，而且简单的数据查询工作决不建议使用store p，因为此时直接sql调用和store p区别不大，特别是使用preparedstatement的情况下速度差别更小。
但是如果存在复杂逻辑过程处理，特别是需要交互且交互过程中出现了大量数据传递时，如果能使用store p则既可以因预编译的存在降低实时sql处理的时间浪费，又避免了大量数据传递占用的网络带宽和出现的延时性，这时的差别就天差地远了。
所以只建议在出现复杂逻辑过程处理或者系统预处理的时候使用store p，其它时候不建议使用。至于什么专家说着说那，别信它胡扯。哪儿来的一个什么破专家？它说取消就取消？kao

Answer 4

再补充: 其实很多J2EE项目都是Stored Proc和CMP混用，尤其是那些本来就有数据库的旧系统。
就象我上面说的，Stored Proc给那些非EJB应用程序用挺好的，很多旧系统因此就建立在Stored Proc上。如果你们的项目仍旧沿用旧数据库，又要保持原有旧应用程序照常运转，那一定是Stored Proc和EJB混用了。这没什么大不了的，很多项目都这样。