存储过程真的好快!

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

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

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

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

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

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

那看你怎么去表示啦，如果用对象的方式去完全映射到关系模型上可能某些地方会存在问题，不同的角度解决不同的问题。存储过程比对象，是从另外的角度去看待的，比如性能等，与设计功底无关，你又说错话了，呵呵！虽然我也是支持尽量把一些简单的业务放到jave代码中，超级复杂的业务逻辑，还是放到存储过程比较好！存储过程实现这些复杂逻辑一方面代码可能会少一些，另一方面维护起来方便一些。另外要说明的是虽然存储过程可以调试，可以查看变量值，但是调试起来真的没有java方便啦，我是这么认为的，呵呵！我就受过那罪！还有重写存储过程，也没有太大难度。

呵呵，以前做企业开发，总是想着事务，数据完整性，外键约束等等，现在做sns网站，前期也把以前的那套也搞过来，发现问题较多，很多时候，像外键之类应用层是可以保证正确的，就没有必要去进一步检查了。做不同类型的应用，思想也需要转变才是。

存储过程调试分析,并没有你所说的那样麻烦.....

存储过程效率是没有话说的，以前做企业应用，跑一些财务方面的报表都是用存储过程计算的。
存储过程调试其实问题不是很大，主要是维护不是很方便，由于它是存放在数据库中的，程序发修改发布时，就得更改数据库，程序移植性也很差。
但是如果你做的应用，需要大量反复的数据库IO操作，又需要事务控制，那么存储过程是不错的一个选择

Robbin说得很对。
半年前我应该还是那种不管三七二十一，一律叫嚣把任何业务逻辑都交给java解决的那一类人。数据库，那就是一个保存数据以便于应用服务重启后能重新获得数据的东西。由于读写频繁，需求的变化也快，用JAVA作为业务的承载实在理想不过。
可是这半年里我转去做数据分析的工作了，也就是数据仓库，这让我的看法发生了很大改变。这个工作要常常面对海量的数据（核心的表都是千万级以上的数据，最猛的那个是40亿+），这种情况业务使用java就不合适了，至少内存就受不了。此外，数据仓库的一个特点就是不要求实时性，也就是Robbin所说的“这些后台任务往往会执行好几个小时才能结束”，“在展示报表的时候读取最终查询结果”。

还是老麦几十年前的那句老话说得好——“媒介即信息”。每种技术媒介都有自己的特点，总有特别擅长的领域也总有不那么擅长的领域，没有什么东西是包打天下的。