关于存储过程的争论

刚来公司不久，今天和项目经理争论了存储过程的事我认为：存储过程是一种很美妙的东西，写起语句来既轻松又流畅比如一个组合查询，如果写在宿主程序里，很多人就是拼接很长的SQL语句（实际上我们公司也确实这么做的）这样一来，程序显得罗嗦不美观，还有可能带来安全性问题，比如经典的口令验证代码漏洞就是如此，如果做在存储过程里，只要传递参数过去，就能轻松搞定，不需要多少废话，简洁又明了，这样，各司其职，只需要简单的语句和返回结果进行交互。项目经理不支持存储过程的理由： 1.难于维护  2 .业务逻辑应该在中间层做我的回答：对于1，我一直没弄明白为什么存储过程一定比宿主程序更难于维护对于2，我理论上和他保持一致的观点，但我同样也保持另一种观点，就是能在数据库里做的事就尽量在这里做除非：
   一：让数据库做的性能不如宿主程序做的好；
   二：和数据库之外的数据进行交互；
   三：和第三方数据集进行交互；当然，中间件的一个重要功能就是负载平衡，但如何不是特别频繁性的操作，还不如在数据库里做，何必非要固执地一定要全部做到中间业务层呢？欢迎大家发表意见

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

我也赞成在数据库中写存储过程，其实难于维护什么的都是托词，看看微软的Duwamish也是写在存储过程中的。
存储过程处理某些复杂的查询，统计，以及关联的更新等等等等
都有它自己的优点
说存储过程难维护，绝对是托词
存储过程一样可以写的清清楚楚，干干净净对中间层的执着也大可不必来抹煞存储过程可以保留中间层，但是实际的工作都是存储过程完成存储过程并没有干涉中间层的概念比如说你一个类本来是用sql来进行数据库交互那么我改用存储过程交互，你就说我这不是中间层了？没有必要这么教条吧
就是因为各自认为都是正确的才有争论由于这个团队都形成了在宿主程序里写SQL的习惯，即使我是如何的正确，也难以对一个团队形成大的影响更何况，对于这个团队，我也是新人所以，有时候郁闷就是来自于这种与其说是观念不如说成习惯的冲突
在中间层拼凑SQL语句的确比较烦，这些时候用存储过程的确比较简洁，而且性能也可以提高。
但也不能老是依靠存储过程，有些逻辑可以由存储过程或者中间层实现的，倾向于由中间层实现。
毕竟频繁的访问数据库服务器会导致性能的下降，而且数据库的开销比较昂贵啊。
to layershow(绿叶兄):  呵呵，看来做一个有影响力的人，是不能靠争辩的

  还是你的方法比较有策略
支持你的觀點，我認為存儲過程也有一定的好處，維護也比較方便，比如要改動一小個的地方，但不會影響很大的輸出結果，改下存儲過程就可以了，用SQL組合就會帶來很多麻煩，需要重新編譯，特別是在多人開發的項目中更麻煩，這隻是個人意見
支持存储过程，维护方便，不用在程序里找SQL了。
如果你的项目要适应不同的数据库,最好不要用存储过程,而且最好用标准的sql语句,这样便于维护和部署,如果只是一种数据库品台,那就选存储过程,对于这个问题MSDN有详细的解答!
中间层尽量短小!!
数据库的连接资源尽量早释放~
各有优缺点，其实就是业务逻辑的归属问题，
到底业务逻辑是由数据层处理(用sp），还是由中间层处理，这个要看程序的复杂程度，
如果使用的数据表很多，并且业务逻辑复杂，那么还用sp处理显然是不恰当的。另一方面，程序对数据的访问不外乎CRUD操作和Load操作，这些其实是可以共用的。
这次我做也是全部sp，感觉蛮好的，但是也应该具体情况具体分析吧，楼上的各位都说的很有道理，study....
有可能会改动的，或者复杂的sql，我会放在store proc里面
很简单的sql就直接写在代码里面拉
sp有sp的好处，也有缺点。大家都支持sp, 小弟说点陋见，1，比方说你是用MSSQL开发的系统，现在要移植到Oracle或DB2，而您又写了一大堆的sp,那移植的成本有多高？相比之下，放在中间层则移植能力提高了许多。2，性能的扩展性，我们知道除了Oracle外，主流的mssql和mysql都不支持负载平衡的群集，故此当高强度的企业应用时只能尽量提高服务器的硬件配置了，而如果逻辑放在中间件呢，则还有CLB等着我们发挥3, 拼接sql语句确实是让人很难受，但也不是完全没有办法的，还有ORM呢所以小弟感觉还是小规模的应用，不考虑1，2点的时候大可用之，但如果项目较大，还是要仔细啊。
1.SP只能使程序更容易维护.
2.SP减少了程序的硬编译.
3.SP可以看成在数据库上增加一层.
我的观点如下：
1、SP如果用在复杂的查询或是业务报表时，是非常的不错。
2、SP毕竟是模块化的编程方式。
3、如果做三层架构的话，那么业务逻辑尽量的放在业务层，维护起来方便。
4、现在很多的服务器，即是做应用服务器，又是做数据库服务器的，对于简单的逻辑，即便是用SP，也未必有多大性能上的提升。
我报表分析，基本上是使用存储过程完成的。一条SQL不可能完成的。
WEB项目中涉及到数据操作的也是通过存储过程完成，因为我觉得这样安全一下。
支持 timiil(小华) 的观点：
    如果系统可能用到不同的数据库系统，就尽量不要存储过程，并且尽量的用标准sql，如果只是建立在单一的数据库系统上，那就无所谓了，各有各的优点。
    但现在做的系统大多都要考虑系统的可移植性，所以本人的观点：尽量不要用存储过程，而是把处理放在中间层，项目中也一直是这么做的
没想到最后一个 zhouzh197895(zhouzh) 跟我的想法完全一样，以前我也很喜欢用sp，但现在我基本可以说完全不用了
我怎么觉得存储过程不是很强大啊？比如当查询条件的参数不确定时，存储过程怎么解决啊？可能是我数据库学的不好吧，但能用存储过程的时候我还是较倾存储过程。可是看到我程序里那些大段大段的sql 语句的拼接代码就很不爽
存储过程不好調試。
在VS.NET中，是可以调试的~~
谁说存储过程不好调试？？在查询分析器中，右键点击你的存储过程   最下面一项是"debug"在.NET中，选择Server - SQL Server - LocalHost ->storeProcedure ->Step in Sp...也是调试这个问题很久以前就在csdn上就争论过总结：   1.如果有比较复杂的业务逻辑   不建议放进存储过程
2.拼装SQL语句   不建议放进存储过程3.碰到类似简单查询、删除、修改  之类   可以放进一个存储过程当中  表示对一个类的操作。
4.碰到需要处理事务，回滚等内容  建议放入存储过程
事物存在总有他的理由，但千万不要教条。是用sql语句好，还是直接用存储过程好，这个没有绝对的要看当时具体的情况。
比如，只是一个简单的select count(*) from tables 就没必要用，另外存储过程是调用以后常驻内存的，对于一些不常用的语句，建议不用。另外，存储过程也不是维护简单或者难的问题，这要看你对存储过程的调用管理上是否做得好，比如，某个存储过程，需要多输出一个参数，那如果你的数据层的东西做得不好，就得到处去找，哪个地方使用了这个存储过程，然后一个一个去加参数。如果数据层做得好，直接改一个地方，那维护还是很方便的。存储过程对于处理复杂的数据表之间的逻辑是很有好处的，速度快，尤其是对需要经常调用的地方，比如一项操作，需要从数据里取出多种数据，那如果不使用存储过程的话，通过ado(ado.net)会要经过几次的操作，效率很低。另外，建议大家首先考虑的是系统的架构，在乎的是设计合理。设计上有问题，其他的东西都是白搭了，尤其是数据库的设计以及各种索引的建立维护等等。这些相对于是用存储过程还是直接用sql调用来说，标准的是西瓜和芝麻的关系。
个人观点,还是少用SP好,
效率是高点,维护真不方便,如有特复扎的,才用,对效率不是太大影响的,就SQL好
1、存储过程比自己拼SQL的优点是显而易见的，所以我主张使用存储过程(以下简称SP)2、但是在有复杂逻辑的系统中SP虽然能够成功可靠高效完成功能，但是大篇幅的SP很难让后来的维护者阅读和调试，容易在业务变化过程中带来高成本的维护代价，而且极大的增加”越改问题越多”的几率。3、把业务规则放在中间层做在业务变化的情况下容易维护，而且结构清晰。但是需要在“结构”“维护”和“可靠”性中间做一个权衡，将大部分的业务逻辑放在中间层，少量非常重要的，需要高可靠性的逻辑直接写在过程中。就是“中庸”之道。4、这个世界实在是太多的不完美了，所以解决方案也总是不完美，但是我们只能选择一个相对较好的，什么好处都占的事情几乎没有。
今天部门经理出面了，强调了公司不使用SP的理由
主要是考虑我们的客户都是大公司，这些公司都购买了不同的数据库版权
所以我们面临的是不同的数据库，可能是SQL SERVER ，ORACLE， DB2如果站在这个角度上看，SP确实不利于产品化但再看看.NET，它为数据库操作做了4组控件包，分别是SQLxxx, Oraclexxx, OLExxx, ODBCxxx如果为了兼容不同的数据库，那么程序代码中势必充满大量的条件编译指令实际操作起来似乎也是很恐怖的。总之，个人觉得，方案有很多种，采用哪种，只是一种选择程序员没有选择权，只有接受选择权，呵呵
拿duwamish7和petshop的例子就可以砸死你们那位项目经理
中间业务层调用存储过程来处理，多少经典的例子都在用它
至于维护，再没有比在宿主程序代码中调试更糟糕的情况了另外有个疑问，你们的项目经理怎么也管这个？做好他自己
应该管的事情就好了
在小型的应用里，使用SP有一定的优势，但是如果一旦用到大型的项目上，或者说以后很有可能需要扩展的项目上，那么麻烦就来了，也的确是不好维护和管理，比如基于WEB开发的项目上就会遇到这样的问题！这是我的经验。
另外写到中间层里也是为了使系统架构更加清晰，这样也为了以后的扩展或修改打了非常良好的基础，也许在开发的时候你考虑到了效能与开发的难易程度，但是对方所考虑到的是扩展性和软件工程中的耦合度问题，这样做不是没有好处，可以让他手下的人，在以后修改系统需求的时候不用疲于奔命的去改写建立在低层之上的业务逻辑，众所周知DB的架构一般是不可撼动的，因为一旦改动将牵制全局，或许在没有做工程管理的时候你不会体会到这样该有多麻烦，当你做上项目经理的位置时，你就会感觉到了
这就说明你不是老板，雇佣这么多人，多少薪资你计算过没有，faints
to AhBian(阿扁) :  按照软件工程的理论，是应该安置各种各样的角色
  可是作为一个公司，也要时时顾忌成本
  不同的规模项目，人员组成也相应有所不同项目经理充当80％的高程，20％的本职，这种情况也是经常发生的
个人认为两者都用,只是用在不同地方和不同的复杂程度.视具体项目而定.不过存储过程的优点很明显,缺点也很明显,消耗服务器资源,除非你的sql 写的十分优化可能会减少部分服务器开支。写在代码里看起来很方便,知道她在做什么,减少系统开销.适当使用是非常不错的选择.
个人认为少用 sp 后期的维护成本会低！因为首先都用 sp 来与数据库交涉，那 sp 的个数真的会很多，当然我指的是大的项目，当 sp 个数一多，里面包含的表，视图操作，那就不好找了，因为维护到后头，会到处都是表，视图的操作，当我修改了一个表之后，需要修改相应的地方，那就体现了 sp 的弊端了，你要从这么多的 sp 里找出用到这个表的地方真的不容易哦！
不知大家有什么高招，请指教！
怎样适当就用什么，具体问题具体分析。至于哪个更好，没有定论。你们听过李维的录音没有， delphi 盒子上一搜就有的，里面李维谈到过这个问题。
存储过程的优点是明显的，但严重依赖某一种数据库。我见过一个大型的系统有几百个存储过程，从sybase移植到oracle时累死了几个程序员，而且不利于分层。比如在j2ee中，一个ejb本来是负责事务操作的，如果干了一半又交给了存储过程，那么对事务的控制能力会减弱，这样的架构必须导致一部分业务逻辑在ejb层(比如数据库层面较少的操作或存储过程不擅长的各种数据结构的操作)，另一部分在存储过程上面，如果有些人再加点触发器(也是一种存储过程吧)，一堆猛料，代码在调试的过程中就象见了鬼，黑黑，这时候就欲哭无泪了
我不喜欢用存储过程做复杂的业务，
虽然效率高，毕竟他不是面向对象的语言，
写复杂和多变的业务没有面向对象语言所带来的灵活。
我觉得不可以拿duwamish7和petshop来说明什么，因为他们的存储过程只处理简单的数据操作。
更何况这两个案例所表达的并不是这些。
我觉得 Sp的参数定义，也如如同于Interface那样，原则不进行修改
这样看来，可以将复杂的Sql实现写在sp体中，可以达到类似COM的效果
同时一些简单逻辑，可以在直接在sp中进行修改
而不用修改任何的程序代码，执行从新编译但是过于复杂的逻辑在sp中实现起来比较麻烦
极力期盼SQLServer2005的正式发布
存储过程不好调试？在PL/SQL中调试存储过程就跟调试程序一摸一样，反正我用了这么久ORACLE还没感觉存储过程有什么不方便的。而且，最重要的一点：在程序中拼的SQL语句只有在程序catch到exception时才知道写错了，而存储过程写错了就写不进数据库，马上就可以调试。
存储过程的优点是明显的，但严重依赖某一种数据库。我见过一个大型的系统有几百个存储过程，从sybase移植到oracle时累死了几个程序员，而且不利于分层。比如在j2ee中，一个ejb本来是负责事务操作的，如果干了一半又交给了存储过程，那么对事务的控制能力会减弱，这样的架构必须导致一部分业务逻辑在ejb层(比如数据库层面较少的操作或存储过程不擅长的各种数据结构的操作)，另一部分在存储过程上面，如果有些人再加点触发器(也是一种存储过程吧)，一堆猛料，代码在调试的过程中就象见了鬼，黑黑，这时候就欲哭无泪了
-------------------------------------------------------------------------------------
其他的应用程序也因是追对数据库的业务逻辑而受益
比如前一阵有个项目
用delphi编写的，业务逻辑都在sp里
总公司用的是c/s,较远的地方采用了b/s结构
直接调用sp可是在b/s里省去了不少步骤，所以换个角度来说
这也是优点
至于数据库的可移植性，相信即使你在宿主程序里写业务逻辑
针对不同的数据库改变的地方也很多，并不是轻而易举的可以移植的
不太支持sp好维护，sp不好做版本管理，sp也不好调试。
sp维护真的不是很方便.
对于多人的工程,他的版本控制也不是太方便.
项目小的话,时间紧的话,考虑用sp
个人比较不喜欢存储过程
存储过程的确维护不方便，又不能调试，目前O/R m 技术已经比较成熟，没必要还把业务逻辑放到数据库来处理
对于报表问题，如果使用强大的报表引擎，使用面向对象技术应该比使用存储过程方便很多，我们目前项目中便大量使用存储过程，造成维护严重困难
对于MS的两个例子为什么使用大量存储过程，个人认为那时由于一旦使用MS技术，便将平台移置列如不考虑的范围中，因此，我认为使用MS的程序员的思维都是跟到MS走的，我也是做MS技术的，对次深有体会