探讨用存储过程的优劣

产品不换，只换数据库呢？ mysql 改用Oracle

我曾经也和.net的同事讨论过这类问题，我是觉的放在程序里好，他是觉的放在存储过程里好，，后来还发了一篇文章讨论，，，，，http://www.iteye.com/topic/734702，至今没找到准确的方案，证明哪个好，只能说在一定的基础上各有一定的用处

高并发下会对热门资源形成竞争性抢占，系统中要抢占的竞争点越多性能越差。你所有的逻辑都用存储过程来执行，很明显所有压力都会集中到数据库服务器上。而这部分压力又不能通过业务逻辑中间件分摊，运行风险很大。我们一般都采用业务逻辑和数据库分开的架构方式，很少写存储过程。一般只用存储过程写关键的、需要高速执行的逻辑。

hehe,我敢打赌这里反对的人都没有用楼主介绍的架构开发过项目。这种架构从头到脚都是动态的，节约的时间不止一星半点，而且从前台到后台都可以灵活的调配人力资源，对于小型团队，每个人从前到后都懂一点，这种架构的开发速度就体现出来了。
我曾经用类似的架构做过商业模拟游戏，局域网对战的那种。这种架构对于中小型项目，局域网内项目是开发利器，尤其对于游戏这种经常修改的显示逻辑。不过确实可维护性差点。但说真的，用mysql写存储过程绝对没有那么的复杂。几种套路也相对容易学会，当然，对人的要求还是稍微高点。
项目开发还是从整体考虑比较好，不是什么时候可维护性都排在第一的。另外，这种存储过程的可维护性差，维护成本高，但有多少这种类型的项目的是需要很多维护工作的呢？

当然，这种架构对人的要求需要注意一些，尤其是后端存储过程这方面，表的数量和存储过程的命名规范和整理需要注意。这些如果注意的好，维护还是会省一些事情的。当然前后台接口定义也是如此。最好都一目了然。
我觉得最大的好处是几个水平差不多的人前后台互相支援，基本没什么等待磨洋工的时间。如果一个团队能比较稳定，做同一类型的项目应该非常快的，动态定制的适应能力非常强。

我刚开始工作，只参与过现在这个系统，是JSP页面+STRUTS控制转向+DB2存储过程实现业务逻辑。平时大多数工作就是在写存储过程和改存储过程。系统在在删除、插入操作时，人一多，经常会出现死锁。另外，DB2存储过程调试很不方便，还有，写的好和写的不好的存储过程，可能一个只需要1分钟得到结果，一个需要5分钟得要结果。
最痛苦的就是改别人的存储过程了，特别是那种经过了几个人修改过的存储过程，简直是悲剧。。。

我感觉，一个运行超过三年的系统，去维护它的存储过程，简直是个悲剧。

如果说，人一多就会出现死锁，那说明是你们系统有BUG，而不是采用存储过程的原因。
比如说有多个地方用相反的顺序在更新一系列表的时候，就极容易死锁，你们该从这方面找原因。

我们系统运行到现在，死锁从来没发生过。
另外，无论是sp，还是java，如果编码不注意，极容易产生耗性能的代码。比如几百次循环用“+”号拼接字符串，这种问题程序员自己测试的时候很容易被忽略。

无论是编码，还是维护，一定的规范和完整的注释是必要的。

把业务逻辑转化到DB上，不太同意！