探讨用存储过程的优劣

维护 估计不会很方便 ；

以前有个搞储存过程的人走人了  根本找不到人来接手那些个逻辑

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

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

我深受其害······························
喜忧参半


(1938 個資料列受到影響) 快2000的存储过程 我的个乖乖

面向对象和面向过程的争论，如果不需要继承，封装，多态，都一样。

SP和Java 差的都能没有下限，20000行的function无论在哪儿都能让维护的人骂娘。不过java相对容易整理，而且java程序员便宜。
说性能什么的先免了吧，这又不是web2.0，scale up无非是钱的问题，不是可能与否的问题。

1：数据库性能问题
2：用数据提供的功能能大幅减少开发量
3：必须用数据库解决
否者没用任何理由用sp来写业务代码，以后的维护，修改，扩展都是大问题，当然看项目的实际情况。如果小项目，都没有问题。
神马都是浮云，用户认可给钱才是王道

存储过程最大的优势却被你免了，这怎么可以。SP是经过预编译和optimizer优化过的，而且可以使用很多数据库特有的sql语句，执行效率比orm要高很多。

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

从我以前的类似的经验看，这种不太适合多个用户并发操作。几十个用户无所谓。有一些java里面的同步处理相对麻烦一点，锁表效率可能会较低，但我觉得进销存不像游戏，不存在这个问题。对于各种查询我觉得存储过程灵活很多，非常快。当然，这里没什么缓存的事情，进销存也无需考虑，做几个视图应该就解决了。或者用存储过程做一些统计数据的冗余。

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