发表评论
存储过程可以并且应该加以适当应用。我建议可以采用下面的流程进行：
1 指定一名数据库管理员（DBA），只有他能够有操作生产环境数据库的权限。此人可以有项目管理者代替。
2 程序员A（Pa）在自己本机上搭建与生产环境类似的数据库环境，并在本地创建存储过程。
3 Pa对存储过程调试无误后，将创建存储过程的脚本放到一个文本文件中，并将这个文件添加到源代码管理。
4.1 DBA从源代码管理中获取脚本，并进行复审，认为无误后，执行脚本在生产环境中创建存储过程。
4.2 程序员B（Pb）可以从源代码管理中获取脚本，并在本地数据库上执行，做到环境的同步。
5 当Pb认为存储过程有误时，可以在本地进行修正，调试无误后修改源代码管理中对应的文本文件，并签入。这样其他人（包括Pa、DBA）都能看到最新的存储过程。
6 重复4.1至5
关于第一条：可以进行版本控制啊，把建表，改动表，存储过程的sql语句都存储成文件不就可以了，还有数据字典等文档。
同道中人！我也是很不擅长数据库编程，但感觉数据库编程还是需要的。
还是要学习的！
基本上是因为你的项目不涉及到复杂的数据库操作，不然你不会这么认为的。一般的以数据为中心的项目，离开了存储过程是不可想象的。
@chnking
数据库越是复杂越不爽，上千行的存储过程你敢随便改？
N多做java开发的甚至连存储过程是什么都不知道，不一样的大项目一个接一个的做，也就只有搞.net的比较推崇存储过程。
@kiler
上千行的存储过程，这么复杂的数据处理逻辑，不用存储过程，在程序里一句一句的sql语句执行吗？且不说效率问题，光是逻辑不用存储过程怎么实现这上千行存储过程代码的功能？
是的，关于可维护性方面，把上千行存储过程代码换成程序代码，可维护性不一定会改善，但不可否认数据库处理有绝对的优势和弱点。
.NETer喜欢用存储过程，因为.Net缺少企业级大型应用架构指南，微软也没有个好的面向对象企业应用方案，所以.Net的程序不少都是数据驱动方式在做。另外.Net的世界里也没有象EJB这样的容器、应用服务器之类的玩意，来解决企业应用里面一般都会碰到的各方面问题。
拿顶级的两个ERP来说，SAP对数据库的依赖性非常小，而Oracle则大量使用Oracle数据库特性，对这两个产品的架构，没有多少人有资格去批判的，都是优秀的应用
感觉数据库编程还不错
我今天上午考试了数据库
估计及格一点问题都没有，嘿嘿
考试的时候才突然发现sql语句太牛比了
呵呵，SQL 的存储过程违背了三层架构，逻辑层和数据层耦合非常明显...
不过带来的是高效率。虽然我本人还不会存储过程，DLinq 够用了...
我也不喜欢数据库编程。
至于原因，数据库编程本身好不好还在其次，主要是我实在不想在写项目的时候同时使用两套思路，我觉得那在美学上是痛苦的，在实用上是低效的。
@chnking,
我觉得只要存储过程能做的，程序语言一定能做，当然写出来的代码可能会比较繁一点，但是这个不一定。
我刚做完一个不大的项目，因为不想做存储过程何触发器，所以在涉及到的地方全部都绕开－用C#写了，所以对这个有体会。
尤其是现在sql2005出来后，可以直接在IDE里用C#写存储过程了，很方便，而且比数据库编程更灵活、更强大。
能避开就尽量避开吧 但没有存储过程确实很多事情没法做 或者说没法在客户能够容忍的时间内完成
@chnking
把存储过程改成程序不是像你想像的，仅仅是是把存储过程里面的sql拿出来再到程序里面堆一遍那么简单，程序可以实现很多存储过程很难做或者做不了的事。
1． 错误处理、流程控制、数据类型等，都和现代的编程语言（如C#）差的太远。比如字符串处理不灵活，不支持集合等。看到有人为了复杂循环而大量使用游标，而在dotNet中记录（DataRow）是数组存放的，想怎么定位修改都行。
为什么会出现上千行的存储过程，上面的原因也是很重要的，有时候如果仔细思考一下，就会发现，其实很多很长的存储过程完全是多于的，写成代码会觉得很简洁的。举个很简单的例子，我有一个数据操作需要要对一个数据量不大的表反复进行遍历操作时，写存储过程的人会一遍又一遍的打开游标反复操作数据库，但是写程序就很简单，就是一次性把所有数据读出到dataset，然后在内存里面反复操作，最后一次性更新到数据库，不用一遍又一遍的访问数据库。那个效率高，那个好维护，显而易见。
我觉得不少人用存储过程用过头了，再举个简单的例子，现在网上最流行的分页存储过程就是一个很典型的例子，其实说白了，就是在存储过程里面动态的拼凑一条sql语句然后再执行一下，这种东西完全可以写在程序里面的，代码还更简洁,执行效率也是一样的，但是不知道为什么总是有人不知疲倦的写着一个又一个这样的分页存储过程，就没有人想过，这个东西也可以在程序里面写的。我非常反感那种做什么都要用存储过程的开发方式。
顺便说一句我不完全反对存储过程，开发中如果是确实性能达不到要求必须要用存储过程了，那就一定要用。
@随风流月
大量的使用存储过程不见得会高效率，尤其是滥用存储过程，你用多了就会体会到的。
@kiler
同意，我就在程序里面组合分页的SQL语句。效果很好。
虽然同样不喜欢存储过程 而且本人数据库极烂
但不得不说 存储过程在效率方面还是有很大优势的
@RicCC
我们的讨论基本上都是以开发项目做前提的，我想园子里大部分人都是做项目的吧，你拿拿顶级的两个ERP产品来说事没什么意义的，产品本身就不需要多高的可维护性的，产品的架构再烂都没关系，反正产品不需要大的改动，只要好用就行，你可以想像一下如果要Oracle的ERP改成支持mysql的，或者是Oracle的ERP产品里面有一半的表结构需要改动，Oracle的ERP产品开发人员会是什么表情，上述改动在产品里面是不可能的，但是在项目中可以说是家常便饭。
我最喜欢数据库编程,我最更喜欢用C#写存储过程了(Sql2005),
但是我最担心的是C#的性能了
@kiler
为什么会出现上千行的存储过程，上面的原因也是很重要的，有时候如果仔细思考一下，就会发现，其实很多很长的存储过程完全是多于的，写成代码会觉得很简洁的。举个很简单的例子，我有一个数据操作需要要对一个数据量不大的表反复进行遍历操作时，写存储过程的人会一遍又一遍的打开游标反复操作数据库，但是写程序就很简单，就是一次性把所有数据读出到dataset，然后在内存里面反复操作，最后一次性更新到数据库，不用一遍又一遍的访问数据库。那个效率高，那个好维护，显而易见。
第一，这样做的效率会很低
第二，复杂数据处理的情况比你说的复杂的多，dataset的功能毕竟有限，更复杂的数据处理它是做不了的。
@chnking
效率低的是存储过程吧，一遍又一遍的打开游标占用着数据库的连接。在内存里面处理业务远比在数据库里面处理业务快。
@kiler
存储过程是在数据库引擎内部运行的，都是经过预编译的。
通过应用接口进行复杂的数据操作，首先要通过各种数据库驱动读数据到内存，然后存到到dataset，dataset本质上是xml，xml是很耗资源的一种数据存在形式，对datarows进行扫描那才叫效率差呢。复杂的操作要频繁的取数据库其他表中的数据进行操作，还要频繁的读取数据。
你说哪种效率高？
@kiler
我的观点是，项目导向的情况下，将业务逻辑放在数据库里面会更合适；产品导向情况下，最好采用domain设计思想。因为如果对数据库、SQL的掌握很好，很多问题很容易解决，使项目进展顺利。当然，如果“产品里面有一半的表结构需要改动”，并且这种改动不是那种附加性的字段，都涉及到主要逻辑，那你用什么方法都没用，因为问题就不是出在代码上。
说了这么多，其实只需要问这几个问题：
手里的项目没有数据库行不行？
不行。
需要数据库没有存储过程行不行？
SQLSERVER的话绝对不行，其它的另说。
没有存储过程的话数据服务器就会闲置，从平衡负荷的角度考虑存储过程也是必须的。
这种问题在存储过程 VS SQL语句的时候已经讨论过了，不需要再拿到这上面讨论了。
关于Source control,可以使用VSTS的 数据库版,看看有何帮助没有
有些东西是一定要存储过程才能实现的，比如写ERP的生产计划，物料需求等，其处理过程是非常复杂的，不用存储过程，不一定能实现！！
其实存储过程用得好，学得好！用处是非常大的！！
呵呵，楼主说的有点绝对了，一般来说我到喜欢把数据库自己的事情交给数据库自己来做，当然我也不喜欢用存储过程，尤其是业务封装在存储过程里，但是很多时候，数据交互慢往往出现在程序与数据库的连接和不停地打开关闭上，这时适当的使用数据库编程会带来质的飞跃，听我们经理说国外的一些地方数据库工程师就干这个事，按照架构师的设想来搭建数据库，按照开发工程师的需求来组织数据，开发工程师只是不断的向数据库工程师提数据的需求，而不需要知道如何处理才能得到自己想要的数据，这种情况对我们来说可能有点遥远，不过程序与数据分离的思想我觉得还是可以借鉴的，不要一味的排斥数据库编程，否则，你的程序也同样会变得越来越复杂。
随便说说，呵呵，楼主不要介意。
@心悦
有体会，一个MRP算法我用了2000行存储过程实现，运算速度可以控制的很好，基本同样数据量情况下，用户拿它跟SAP相比，时间不比SAP差
后来产品升级，使用ORM，把这个MRP算法移到了领域模型里面来处理，逻辑复杂度降低到原来三分之一的样子，数据量不到原来的一半，算法一次次优化，并且出于性能优化考虑还在模型里面添加了部分复杂SQL，性能还是远不及原来的方案。
不过关于数据库服务器和应用服务器的负载均衡上是最需要关注的问题，数据库服务器放置了过多的逻辑导致负载过重，会给整个应用造成硬伤，因为数据库的分布比较麻烦，不少情况下应用程序还需要配合做相当大的调整。也正是出于这个考虑，才在新的版本里面将算法移到了领域模型中。
请教楼主:我在一个项目中不想用SqlServer,因为这样的话人家得自己维护数据库,如机子重装后就得安装数据库等问题...所以我想用文本储存的方式来进行数据操作,而这个文本不能简单的由记事本等软件打开...请问如何实现呢?
＠RicCC
哈哈，你现在的项目也用Nhibernate啊，
我们多交流！！
深有同感
像分页器这种东西,用存储过程写确实太多繁琐,何不在程序里动态拼串,高效简洁且易于阅读
程序是拿来给人看的,偶尔在电脑上运行而已
@chnking
然后存到到dataset，dataset本质上是xml，xml是很耗资源的一种数据存在形式
我算是长见识了，我要去好好补补dataset的知识再来和你讨论讨论。
什么语言工具都有自己的优缺点，聪明的人会取其长弃其短。
@RicCC
我说的产品里面有一半的表结构需要改动就是指的是那种附加性的字段改动，这种改动如果系统用的是orm的话，明显改来比用存储过程要快。
关于你说的那个MRP算法，我也说过，我也不是完全排斥存储过程，必要的时候还要要用，比如比较复杂数据操作，反正现在用Nhibernate也是可以调用存储过程的，但是一个系统里面并不是所有的表都要进行这么复杂的操作吧，我相信大部分问题还是不需要动用存储过程就可以解决的。我觉得一个项目始终要把可维护性摆在前面。
#40楼 [
楼主]2007-06-26 08:48 |
@补丁
不管是ms sql Server和Oracle，我的理解和把握能力在本公司里都是属一属二的，但我有个缺点就是不会写复杂的sql，正因为这，我总是把复杂的问题分化为多个简单的问题分别处理。
@chnking
dataset本质上是xml？也许DataSet和xml文件互换比较方便，我认为DataSet是DataTable的集合，DataTable是DataRow的集合，在内存中集合的定位速度当前很好，我有时为了快速定位一个DataRow，会把所有DataRow同时保存在一个Dictionary中。
感谢大家参与，我不喜欢用数据库编程，当前不是排斥他，就像教科书的goto，如果在某个地方很好，我还是会用的。
存储过程的优势在于本地处理，在大量数据读取运算时显然比Client高，但这种高效很多时候不是体现在运算上而是传输上（在同一逻辑频繁读取不同数据特别明显，如果数据一次性获取然后运算处理其实差距并不大）.不过很多人忘记了效率高低的致命点很多时候是代码本身。
我个人认为，存储过程是有它一定的好处，但他的缺点对于项目开发的影响也是不可忽视的，当你面对一个有几十个存储过程，几十个视图，再带点SQL函数和触发器的项目时，你的反应是什么呢？
一个项目我们不能只求运行效率，速度慢，升级硬件也就不慢了吧，MS出VISTA的时候有没有考虑你的机器慢呢？如果你说VISTA慢，那当XP或是２００３诞生时你是不是也感觉他们慢呢？我们现在应该认识到向前兼容，注意，是向前而不是向后，现在硬件的价格足以让我们了解到向前兼容的意义
最大的原因是,你并不精通数据库编程
2007-06-26 08:19 | 补丁
=======================
精通又怎样？你取说有我精通吗？我说你是没有精通数据库方面的应用程序开发~~~
我同意作者，
@kiler
分页写成存储过程，这两个也算原因吧：
1.分页程序逻辑上独立，一般写好后不需要做修改，做为存储过程放在数据库中就是独立的一个文件，使用方便又带来些效率上的提升。
2.分页存储过程独立于语言之外，写好后放在数据库中，不管是asp.net/asp/java...，只要写一次。
@chnking
我看到你提到的上千行存储过程不便于改写成C#的问题
但我的第一反应是，你怎么会出现上千行的存储过程，这不得不让我对你的数据库设计的健壮性产生了怀疑
以我的经验，出现大量存储过程的可能有几种，其一就是数据库设计的不合理，其二呢应该是在存储过程中参与了大量的逻辑，再有就是版本无控制，或多次修改产生的结果了
我猜想你的程序逻辑层已经退化了，因为让存储过程抢了饭碗，这样的问题就是把大量的难题留到了日后的维护中
还有DataSet是有些占资源，但要看你用的是否合理，或怎么用了，还有DataTable和DataRow可以用呀，但DataSet并不是XML
其实大家也不要挣了，我看这里讨论的人大多应该都是.Neter，VS2005已经支持C#开发存储过程了，我们还挣上个世纪的技术有啥意思
我觉得那是应为在数据库编程上的经验比较少的原因。数据库编程在很多时候也有优势的。比如批量数据操作使用存储过程会有性能优势，我参与的一个电信级的应用，全省用户的月帐单多达千万条，数据处理不会存储过程是不可想象的，随然我不太用触发器。而且我觉得很多时候数据处理逻辑写在数据库端，安全性和可移植性也比写在程序中好。不论是java还是.net都是这样的。而且数据库本身的事务控制写起来很简单，容易实现；最后，前面好像有人说数据库编程的错误处理不容易实现，其实数据库是非常容易捕获数据错误，有些经验的人都知道。总之，法无定法，式无常式，视情况而定。
象我写的eform自定义web表单工具软件,是需要能在各种数据库下使用的,如写多了存储过程的话,想兼容各种数据库就不可能了.
#51楼 [
楼主]2007-06-26 09:52 |
@克隆
C#可以写sql2005的存储过程，没错，但不能写Oracle的存储过程，并且我试了一下，C#写的存储过程好像不能传递DataSet和各种集合类型为参数。
@钱彦云
我说过，我并不是一定不用存储过程，如果用存储过程执行一个任务只需10秒，而写C#代码执行需要30分钟的话，无论是谁都会选存储过程。再说我写的都是小项目，没有5000万条记录需要即时处理。
我觉得可以不用储存过程，就不用。
自己做过一个系统，用了一百多个储存过程，当要修改一个表结构时，你即不知道哪个储存过程用到这个表。
还有，如果要移植数据库时，工程量很大。一般的软件公司，你永远不知道客户的需求，特别有些客户用的是用正版数据库情况下。
楼上的可以用一个系统SP查到表的依赖关系：
sp_depends @TableName
对于OLTP，当然能不用sp就不用sp,但对于OLAP，想不用都不行。
一般来说，不建议使用游标！
SQL还是有循环的，再复杂的循环也不一定要用游标的。
什么都不能绝对下结论，有时候你在一个事务中处理5、6个表的数据复制、更新，换成C#可能需要写几百条SQL语句，你受得了？
或者从几十个G的数据库中、统计综合报表的时候，我碰到过的应用每晚要跑1-2个小时，可能用java或C#都没计算出结果就连接超时了，你不用存储过程用什么？
。net程序员不考虑存储过程可以理解，毕竟SQL Server用的多，数据不会很大。
學現在我的編程中很少用到存儲過程和觸發器。。看了各位高手的經驗之談。。對這個東西有了一個比較概念的認識了
@kiler
我有一个数据操作需要要对一个数据量不大的表反复进行遍历操作时，写存储过程的人会一遍又一遍的打开游标反复操作数据库
数据库是面向集合的，一般来说游标是最好不要使用的，如果过多的使用游标，特别是嵌套游标，那么这个存储过程通常是还有优化的余地的，我记得“SQLServer宝典”上有一句话：“游标是有害的”
@zixin
“游标是有害的”,这个我清楚，但是很多写存储过程的人特别喜欢用， 有的人大量使用游标，仅仅是为了在存储过程里面实现类似数组的功能。进行循环操作也喜欢用游标。我不反对使用存储过程，但是我反对滥用存储过程。
@RicCC
刚刚拜读了大作。显然，大多数程序员非dba远达不到你的水平，所以观点不同了。
楼主"不喜欢数据库编程"喜欢c#那么我建议你升级到sql2005，再看看http://www.cnblogs.com/DavidFan/archive/2007/05/16/748300.html
我的这几篇小随笔
但是你不喜欢也还是要写呀，存储过程，游标，触发器等等，存在就有合理性，一些情况下还是相当有用的！！
从DBA的角度来说，存储过程意味着效率和维护的便利，当然维护是和修改代码比较而言。对于复杂的多表、大批量数据更新，不使用存储过程而是通过SQL语句执行效率是很低的。对于开发人员可以不考虑效率，但是对于DBA来说，这意味着大量的连接，多次的SQL语句解析和执行，这是很难接受的。
有些情况是无法避免存储过程，以前有个项目，属于二次开发，现有系统中的出入库数据有四千多万条数据，围绕这个表需要做很多业务报表，直接用SQL语句查询可能30分钟都得不到结果。
至于触发器，大部分情况下都不被推荐使用，由此带来的问题非常难以追踪，尤其是对于数据库不熟悉的情况下。
个人认为学习存储过程也是对自身知识强化的一个手段，很多情况下需要存储过程，需要我们了解生产数据库的特性并合理应用。我想大家都是把自己放在一个更高的角度去考虑问题，多考虑一些性能、安全、健壮的东西，自然会对存储过程有一个比较客观的认识。
另，@随风流月
Dlinq固然是好，可是要投入到实际的生产项目中还为时过早。我不想说什么你还小之类的话，不过把你靠编程兴趣研究的那些东西放在这个场合去讨论，不合时宜。
新技术能够带来生产力的进步，但是在实际的项目开发中，如果没有对新技术充足的储备和研究、评估，不会冒这么大风险、这么大成本去用什么新技术的。
呵呵，我也不喜欢用，可惜我觉得用不用这个事儿leader说了才算！
难道大家都用ORM吗？ORM有多好用，我还没用过。
我反正不喜欢在C#代码里面拼Sql脚本。
我觉得应该各取所需。一个功能，做成存储过程方便有利，我就写成存储过程，直接在C#里面处理容易，我就在C#里面处理。
会了, 精通了也不一定喜欢.
就像曾经精通汇编的人用了 C, Pascal 这样的语言, 并且习惯了, 肯定不会滥用汇编.
这就是境界......
曲滨*銘龘鶽 to 博主
一．不能进行版本控制（印象中Ms Sql的好像可以加到vss，其他数据库不知道）
因为不能版本控制，所以就怕代码丢失和回滚。为了保存回滚信息，故有大段的注释的旧代码，有时旧代码量超过了实际代码，也没人删除。更不能保证多人编辑时的同步问题。
*RE:能版本控制的、你们不会都是直接在数据库里改完了不保存一份到VSS上吧，我们做的时候都是数据库VSS里格有一套有问题以VSS为准。*
二．不能统一代码管理（代码备份）
有点规模的开发过程，都要求有代码管理系统，如vss。但这数据库中的这部分代码却在vss之外，需要单独的管理。也许可以加到vss中去，但也不太方便。
*RE:和上一条一样的问题不要在重复了*
三．编程不便，
1． 错误处理、流程控制、数据类型等，都和现代的编程语言（如C#）差的太远。比如字符串处理不灵活，不支持集合等。看到有人为了复杂循环而大量使用游标，而在dotNet中记录（DataRow）是数组存放的，想怎么定位修改都行。
*RE:存储过程等根据数据库不同，提供的东西也不同就像 VC，C# 看似有些像其实很多地方是不同的，oracle 是支持集合的、不过临时表也可以替代、数据库是脚本语言不要期望它能有aoao 强的功能*
2． C#是面向对象的，写出来的代码相对要优雅，多点代码也容易懂，对象间的调用也易理解；而存储过程中代码多了就不好玩了，存储过程嵌套调用也好不到哪去。
*RE:同上 脚本语言都是很难维护的 javaScript 也一样*
四．调试不便
虽说现在的存储过程也可以单步调试，但调试一般是应用程序发起的，再跟踪到存储过程，两处调试终归不便。
RE:这个啊就像以前3层程序一样跨应用调试本来就不是很容易的
五．错误隐藏
1． 触发器对不了解系统的维护人员，会造成找不到北的错误，永远也不知错在哪，最后才发现是一条触发器惹的祸。
2． 大而复杂的存储过程，也让人头大。见过上千行的存储过程，也许程序员开始并未想到写这么长，只是后来越改越长，控制不往了。
RE:这些都是开放技术熟练度的问题、如果是一个不会C# 的 “DB开放人员”你让他去看C#的程序他也许也感觉很乱。
总结:
一二：是博主的项目管理上的问题、
三：那正常的语言和脚本语言比较有失平衡，就像 javaScript VS C# 一样没啥意思了
五：这个就是谁更会什么的问题了。
在项目中使用什么技术其实是、根据项目和人员维护等多种因数决定的
没有说什么技术好不好的、只有适不适合。
作为程序员不要老想让“事物”来适合你、而是应该你来适应“事物”
哈哈，感觉很多人对软件，对程序看法，
太简单，太单纯，视野不够宽（装一把）。
现在几乎是个写程序的人就讲OOP，设计模式
当然这是没有错的，但这不是全部。他只是
一种方法论，目前只有在程序语言中，能够
比较彻底的.但是OOP只是方法论，就是解决
问题的方法指导，不是目的。目的是高质量的
解决问题。
一般的MIS系统，都可以分成2部分，一部分
有开发工具实现，一部分有SQL 实现。
SQL 是用来干什么的?是用来处理关系型数据的。
既然系统里有关系型数据，而SQL就是用来
做这个的，那么为什么不用呢？
当然对于数据库编程不熟的人，这个确实不是
很有乐趣的事情，不像什么OOP，模式，AOP，
说起来那么酷。
好了说了这么多，其实很简单。你可以用OOP的
思想来用语言做开发，实现。其实你也可以OOP
的思想来写SQL，关键的是思想。
最后关键的现在的数据好事很多年前的关系型数据库
而开发语言已经经过了多次变革，改进，所以矛盾产生了
不过个人觉得，只要数据库还是关系型的，那么OOP
的思想的贯彻就是极其有限的。如果一定要在这个思想下
强行OOP,个人持悲观态度。
存储过程太烂了，真的，一旦有BUG那很难解决，我最讨厌那种天天以自己是ORACLE高手，以存储过程见长的开发人员，MVC为什么要这么分，他们跟本不懂得，业务逻辑都跑持久层去了这系统还有什么维护性啊！！！