存储过程真的好快!

事实上，在OO流行或者ORM流行之前，SP是最可移植，可扩展的方法。我在OO的早期，一般都是把一个业务方法封装到一个存储过程中去的。

现在除了OLAP没啥好说的，OLTP中，如果数据量比较大的情况，除了数据库任务相当繁重的操作，业务逻辑建议用纯OO程序实现（一般业务逻辑只是影响少量记录），结转，报表，统计等等还是建议用存储过程。

关键要看自己的团队的知识层次如何，   还要看看将来的应用环境是什么？

如果你的团队都倾向数据库端，数据库技能强，   那么如果你一个人去偏向JAVA， 这个恐怕团队都没法领导。   反之亦然    。

如果你面对的是遗留系统或者海量的数据，   那么把业务逻辑都放的JAVA里肯定不妥
因为我们知道内因才是决定事物的根本因素，有些问题还真得从数据库内部来解决。

当然如果用JAVA等相关的技术是比方便的，那就要大胆的用，

一句话，要计算好投入产出比！

嗯，和我们的方式基本一致。

我不知道还有什么？
如果你公司叫google，你会说钱不是问题，为了提高性能，你花很多钱
但是你公司非google，你会说问题是没钱，为了省钱，你接受很低性能

非常支持“业务决定技术”这个观点。
我现在是在做供应链系统，大量的报表，大量的数据统计，这部分用存储过程。
对于数据的维护，业务逻辑，用前台程序实现最好了。

对于javaEye这样的数据维护和展示型程序，用存储过程干不了什么事情，反而会增加复杂度。

存储过程维护起来真的很痛苦！

如果不是做数据处理，我们干嘛还讨论这个问题呢？如果一个操作可以不依赖数据库来做，那它造成性能瓶颈的概率也非常小，即使有性能问题也总有N种办法来解决。唯独就是最终要落到数据库的那些操作，比如从几千万条记录里面实时取出符合条件的100条，恐怕是应用层再怎么集群也无能为力的。

补充两个容易被忽视的因素：

1、业务的复杂程度。BBS或者淘宝都属于内容发布型的应用，大多数的业务逻辑都相当简单，而企业应用的业务逻辑可能要复杂得多。大型ERP系统里面，对一条订单行做出库操作，可能会牵涉N多子系统，几百个的表的数据更新，而且几乎没有缓存可用。这时候应用层与数据库频繁往来的开销就相当可观了。

2、lock的问题。企业应用里面很多操作是要锁定一部分数据，部分或全部防止其他用户对其进行更新，然后才能接着往下操作。像“lock a; lock b; sum(a)+sum(b); write c;”这样的操作，如果不是一把在数据库做完，性能也会很糟糕。

学习了,数据量IO密集型的业务逻辑放db服务器,计算密集型的业务逻辑放app服务器

还是看系统要求了 不过存储过程难以调试难以维护的问题确实是悬在头上的一把刀啊 反正俺是能不用就不用 不排除没办法不用的情况~ 最近在搞DB2深刻怀念oracle啊