我不会存储过程（因为java中从来都没有看到过它），但也来凑个热闹，不对之处指正。
我认为存储过程的主要好处就是性能好一些，但是，对J2EE“许多”应用来讲，用存储过程的应用不一定就性能好,比如：
1）用存储过程，可能使中间层的缓存优势没有了（如果对业务逻辑的结果或者在界面层缓存，空间效率可能会非常低，而且很多情况根本就不能缓存，比如里面包含了权限）。数据库虽然可以缓存，但是访问存储过程必须通过JDBC驱动，socket连接，数据库的XX操作等等，就消耗了大量时间，prevayler的内存查询比mysql通过JDBC快3000倍（mysql缓存所有数据在内存），当然存储过程可能好一点点。
2）多数企业应用强调的性能，我的理解，不是单个响应性能，而是伸缩。而J2EE应用伸缩性的瓶颈很多都是在数据库和JDBC驱动，如果把逻辑执行也放入数据库中，又没有中间件缓存，加重了数据库服务器的负荷，而且JDBC调用次数会增加，高负荷性能会大大下降。而如果你的逻辑在中间层，中间层使很容易伸缩的，比如缓存，集群的技术都很成熟。
除了性能之外，存储过程恐怕没什么优势可言。
我觉得存储过程和其他东西完全也同时存在，就像CMP,Hibernate可以和JDBC同时使用一样，对必要的地方进行优化。
真是受不了
这个贴子该结束了
系统已经有了太多不必要的申索性了
真是“为了EJB而EJB”没必要。
:P说简单点，用PHP和存储过程就解决简单问题
另外，我没有说EJB，也不是EJB系统才又伸缩性，需要组件形式的也不一定要EJB，IoC＋AOP更简单
不排除其他的简单的
只是要伸缩性能，适应复杂度，业界公认的成熟热点更值得关注
好像：有了彩电，彩电肯定是主流。黑白的可以解决问题，很少人用了。
当然，技术实现讲究简单性。但也要想到扩展，与主流关注。
另外，提示分布式的n层主要针对业务的复杂性，不适合数据量多多的传递
此同意以上robbin之观点。
那是当然，从"business view"，绝对用成熟的技术
EJB虽然挨了一些骂，但毕竟还算是非常优秀的，而且也会不断的发展改进，吸收新东西
>>与主流相关
从我个人角度我就不喜欢jboss对J2EE的单独改进，也许只有开源组织才有这么大的胆量（tech > biz），我想这是要冒很大风险的。而且要把应用捆绑到一个服务器身上，更不用说它现在的实现受到很多批评，感觉jboss也许已经过了颠峰时代了。
说来说去其实还是得看系统要求, 没有一种解决方案是打遍天下的.
oracle把数据库划分为两种, 决策分析(DSS)和事务处理(OLTP).
他是基于数据存储特点来划分的, DSS中大量数据查询和批量数据调入多.
OLTP中小量数据同步插入和更新多. 数据操作的不同导致数据存储参数设定的不同.
在开发方式上, 我们也可根据这个来划分, DSS架构用command模式配合存储过程, 这通常是两层. OLTP架构用数据对象模型驱动, 是用多层还是两层, 主要是看系统有没有分布式的要求.
系统分发方便或移植容易等等. 不能做为设计的依据. 两层系统也可以通过客户端自动更新来实现系统自动分发. 存储过程也可通过编写sql dialect来完成不同数据库的移植.
在大型系统中通常这两种架构同时存在, 这也是为什么大多数国外项目组里即有java programmer, 又有pl/sql developer.
终于有点结论了，看来不用争了
这种帖子总是回的最多的，是不是因为技术含量太低了？
Can hibernate support JDO standard?
------------------------------------------
> oracle 推荐用toad
> 7.3，我这里有，比sqlplus强多了，PLSQL
> devoloper没用过，不知道有没有toad好
QuestSoft的TOAD适合做Oracle数据库的数据管理和数据维护，但是要说到开发，特别是写store procedure，还是推荐QuestSoft的另一个软件SQL Navigator，专门用来写store procedure的，开发功能比TOAD强得多。
--------------------------------------------------
我以前用过toad功能的确不错，但是后来写存贮过程比较多的时候就改用PL/SQL developer了，PL/SQL对于写存贮过程更方便，但是测试的功能有点怪，习惯就好了。SQL Navigator我没有下载到，不知道那里可以找到。
官方网站就应该有阿。很多地方都可以找到注册码。
JDO or CMP?
Java Data Objects (JDO) and Enterprise JavaBeans (EJB) Container Managed Persistence (CMP) were developed concurrently, but took different paths. To see where each technology is applicable, read the following article. You can also read a Chinese translation of this article by clicking here. Check out the discussion of this article on TheServerSide and support JDO by adding your own views to the discussion thread.
JDO's design center is making Plain Old Java Objects (POJOs) persistent in any tier of an enterprise architecture, while CMP's solution is container-bound with elaborate requirements for development and deployment.
The similarities and differences between these technologies has been the subject of debate since the specifications were published. For example, see the discussions at JDOCentral.com.
抛开是否有好的免费的JDO产品实现这个问题，单从实现的功能来说，目前JDO在多方面明显不如Hibernate。
1、JDOSQL不如HQL
JDOQL功能没有HQL强大，也没有sql统计函数，HQL完全覆盖了ANSI SQL92中的select语句。
2、JDO的映射关系管理没有Hibernate灵活
JDO映射关系没有Hibernate那么灵活和强大。Hibernate的映射关系更加fine-grained，支持多种复杂关系的映射，包括类继承，包含等等，甚至通过自己编码实现ClassPersiter来实现动态映射，调用存储过程等功能。
3、JDO的持久化对象的状态管理不如Hibernate
JDO PO在编译之后，要用专门的Enhancer工具对编译好的POclass文件手工处理，替换成Enhanced PO。在运行期，运行的是Enhanced PO，而不是POJO。其缺点是POJO是从JDO StateManager中取values，而不是从POJO的实例中取，因此在PM关闭以后，不能对POJO进行get/set了。
Hibernate PO是在运行期由CGLIB动态生成PO的Enhanced PO。因此可能在运行效率上稍稍不如JDO的编译期生成Enhanced PO。但据Hibernate作者Gavin King所说，由于CGLIB极其高效，效率损失微乎其微。但是运行期生成Enhanced PO带来的好处是非常大的，对于开发者来说，更加纯粹的POJO，更加简单的开发过程，支持增量编译，增量调试等等。
4、JDO难于实现PO的跨Session管理
Hibernate 的PO可以在Session关闭以后继续使用，因此是更加纯粹的POJO。PO可以跨越Session。而JDO在跨PM的时候必须把POJO拷贝出来VO才能进行存取，因此无法实现跨PM的POJO的状态管理，而Hibernate则轻松做到此点，特别是在分布式环境，例如EJB中使用的时候，Hibernate的PO可以直接充当VO，序列化传递给远程客户端，而JDO做不到，必须把PO的数据拷贝出来，到VO中，再把VO序列化传递给客户端，这一点，是很多使用JDO的程序员感觉很不爽的地方。
如果只就一个简单的技术点的讨论可以有个很明确的结果。
对于系统的解决方案或者一个开发框架来说，离开需求单纯的讲技术好像没有什么意义吧。
每一种技术都尤其针对的应用，但也尤其无能为力的领域。所以去争是EJB、N层结构好还是存储过程好，感觉从一开始争论的双方就不是在争论同一个问题。
从来不觉得那种技术很好或者很差，能解决客户的需求就是好技术。