也论该不该在项目中使用存储过程代替SQL语句

也论该不该在项目中使用存储过程代替SQL语句

2006-08-25 10:58

存储过程的好外,我就不多说了,想必各位都已了然于胸
当然,存储过程也有不少坏处:
1,当存储过程数量越来越多的时候,在众多存储过程中找到想要修改的存储过程是一件麻烦的事.
2.如果用嵌入式SQL语句,可以在修改代码时,顺便就修改了数据库操作语句,方便

针对这两个所谓的缺点,我提出我的一些看法:
1.如果说存储过程多了,不好找,那你该检讨一下您的命名习惯是否规范是否达意,如果是多人合作的团队,大家更应该对于存储过程的命名有一致的规则,当然,不只存储过程需要这样,其他部分也都要需要这样.好的存储过程命名最好能包含操作名称(insert/update/get/list等),要操作的对象名称(表名)等,这样,即便你的存储过程再多,一样也能快速找到要改的那个,这样命名,还可以让你通过SQL 2000的对象查找功能一次性的按表名找到与此表相关的所有存储过程的名称,同理,你用LIST来查,也可以查到所有LIST功能的存储过程
2,对于第二种观点,我是不大同意的,在过往的例子中,我发现,将SQL语句从代码中分离出来,带来的好处远远大于坏处,而且这样更符合分层的原则,如果我们将SQL语句嵌入到代码中,当你仅需要多获取一个字段的值,或者对SQL语句本身做一些修改时,你就必须要编译,然后上传DLL,而如果你是用存储过程的话,你直接改一下存储过程就好了,而且,将二者分离,DBA写好存储过程,列好说明及使用规则,交给负责写DAL层的同学,DAL层的同学闭上眼无需了解SQL语句,也可完成他的工作,因此,从这个角度来说,很好的分隔了工作,不必要要写DAL层的同学也是SQL存储过程高手了
3,防止注入攻击,如果不用存储过程而用嵌入式SQL,你势必要为了防止注入攻击而对输入的用户数据做更多的处理工作,例如处理一些SQL敏感字符等
4.更为重要的是,如果你要朝一个表中插入的是一个BINARY内容的时候,难道你会用SQL语句吗?
5,嵌入式SQL特别是拼贴SQL语句,一向是比较容易出问题的环节,而存储过程在写的时候,就经过检查,储如漏掉符号,INSERT的字段数目与参数数目不一致的小错误,会立即被纠正
6,谁都知道存储过程是预编译的
7,如果你是高手,你可以分析并优化存储过程来提高性能(以前记得看过MS的一个牛人技术支持讲述存储过程分析和优化,非常启发人)

最常见的是,在实际运用中,为了减少DATASET数据集的大小和提高性能,通常我们只SELECT当前需要的字段,但是,随着发展,你可以需要其他字段,这时,如果用嵌入SQL,就要修改SQL语句,编译,再写上绑定该字段的表达式,但是,如果用存储过程,你只要绑定表达式,然后给存储过程中加上这个字段名就可以了.
再如,如果用STRING来拼贴SQL的INSERT语句,那很可能是这样拼
string strSql="insert into table (id,username,password,address) value ("+Id.ToString()+","+UserName...
这样拼贴,多加个字段时,一花眼,就拼贴错了
如果用存储过程,你顶多用
SqlParameter myPara=new SqlParameter("@field5",Field5);
再在存储过程里加上这个输入参数就可以了,和修改一下SQL语句就行了,SQL还会在修改过程中帮你检查语法
后者显然比前者用那么多+号与双引号拼贴出错的几率小多了

最后,以上观点仅体现个人观点,不过,绝不是书上看来的,而是自己做了几个项目,边做边体会到的

-------------------------------------------------------------------------

评论
# re: 也论该不该在项目中使用存储过程代替SQL语句
我觉得一般的crud放在程序中最好,复杂的查询和操作就用存储过程
debug 评论于 2006-01-10 15:54 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
就说CRUD的C吧
如果用SQL语句,你没办法接收到新生成的记录的IDENTIFY值
如果用存储过程,你就可以用return(@@identity)来获得这个值了
而且存储过程支持返回值
菩提树评论于 2006-01-10 16:18 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
对于1条
1.写好开发文档
2.有SQL代码代码规范
3.从UI->CLASS->存储过程的查找方式

存储过程还有个问题就是现在没有非常有效的存储过程版本控制软件

另外获得identity的问题，可以用;号隔开两条SQL语句获得

ttyp 评论于 2006-01-10 16:42 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
存储过程好，但是如果一个web对应多个数据库的话，SP就得在每一个数据库中都放一份。但是SQL如果写在代码中就不用了～
Boler Guo 评论于 2006-01-10 16:46 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
存储过程最大的好处是什么，就是性能。还有就是复杂的处理情况。
因此，如果不是为了考虑性能，一般情况下我不喜欢用存储过程。因为存储过程带来的麻烦问题也太多了。
就如前面说的CRUD，我们的程序开发是在前进，程序开发是面向业务的，而不应该面向数据库。
存储过程让很多的东西都回到了数据库，程序的修改或是什么的，都会涉及数据库，移植性也差。

但如果说系统的对性能的要求很高，而且数据量也确实非常大，那么在没有替代方案的情况下，应该是选择存储过程的。
听棠.NET 评论于 2006-01-10 18:11 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
因事而议，不能一棍子打死
try 评论于 2006-01-10 18:14 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
提一个问题，如果应用程序要求后台数据库能够支持SQL Server、Oracle、DB2任意一种或者混合使用，用存储过程是不是太麻烦？
旭升评论于 2006-01-10 18:36 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
As for me,stored procedure has the below disadvantages:
1.Difficult to maintain
Stored procedures are difficult to maintain,especially in an enterprise system
2.Porting problem
Stored procedures are highly bound to special DBMS,which means if you wanna port your application to another DBMS,it isn't an easy thing if you use a lot of stored procedures.
3.Performance problem
If used appropriately,stored procedures can improve your system's performance.But if you use inappropriately(such as encapsulating a lot of logic which has nothing to do with DB),stored procedures can be a burden to your DBMS.
qbhua 评论于 2006-01-10 19:11 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
使用存储过程移值性不好就是个问题，
但有些时候，不得不把SQL直接写在代码里面。还是需要根据实际需要吧。
kuku 评论于 2006-01-10 22:34 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
我认为你的观点有些不妥：

1. 用普通 sql 取不到插入的 id 值？
简单的用
insert ...;
select SCOPE_IDENTITY()

就能取到了。

2. 说 sp 的调用就可以用 SqlParameter 因此没有安全问题，普通的 sql 就一定要用拼接的写法，从而有安全问题？这个完全没有道理。拼接 sql 是不管你写何种方式的代码都不被推荐的一个做法。

3. 关于性能，sp 的性能优化其实很有限，不要迷信这个。经常使用的 sql，数据库也会作出优化。差别没有你想像的大。

其他。。。

还有几点值得商榷：
1. 不是每一个公司都有专职的很厉害的 DBA，对于一般公司，一般开发人员而言，写普通的 sql 来的更实际。
2. 我推荐只有非得用 sp 来处理的复杂统计才用 sp.
3. 要知道 n 多 sp 和你 n 多对应的 .net 的数据访问方法的代码之间，sp 的参数列表就是一堆麻烦的接口，你需要维护它的。
4. 使用 sp 不利于数据库移植。

建议你阅读那篇著名的讨论：
"why stored procedures are bad?"

木野狐评论于 2006-01-10 23:12 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
与很多人认为的相反：存储过程的效率是最低的。
初看起来，存储过程最接近数据存储的位置，应该具有最高的效率。但是，当程序的规模大到一定程度后，复杂到一定程度后，决定效率的就不再是距离，而是分布式性能、并发处理性能、数据缓存、任务调度的合理性、离线处理的性能……这些性能靠存储过程都是很难实现的。
一个主要依靠存储过程实现其业务逻辑的系统，发展到最后很可能是个数据库不堪重负，维护者感到无可奈何的系统。
对于一个规模较大的系统，不要过多的使用存储过程，当成一个database gateway是可以的，不要让他依赖任何业务逻辑。
小陆评论于 2006-01-10 23:23 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
我接触过的一个项目，1k多存储过程，就算命名很规范，要找到像要修改的存储过程也不是一件容易的事。。。
麒麟.NET 评论于 2006-01-11 01:10 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
哎,又在说这个,老话题了.其实很多这样的讨论,建议楼主先去google搜索一下！
又说这个？评论于 2006-01-11 08:39 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
我觉得如果处理比较复杂，在程序里写sql肯定有问题，至于拼接，更是难以维护，另外在web程序中也会由于增加网络传输的负担等问题，所以这个时候应该用存储过程更合适一些。
而像普通的sql语句，写在程序里也最好用一些现成的组件，如微软的Daab,语句多用参数，而非拼字符串
还有，现在争论这些似乎都有些过时了，现在更多的人都在研究orm来更好的实现程序和数据库的分离，这个方向也许更值得关注
铱星评论于 2006-01-11 08:48 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
我同意小陆的意见,本来昨天就想回复的.

我作为3名核心工程师之一搞过省级电信的某系统,海量数据库,很多表每天新增的记录都是数百万级别,第一期工程就是用的存储过程,极不稳定(要求后台24小时无人值守的工业级系统,却每过几天服务器要当机1次),再括号-第一期工程师A,10年来月薪最低时5万人民币,工程师B,江总书记接见的全国技术精英10佳青年-再括号结束. 系统确实很大,出了问题查起来真累,哪怕这些牛人去查,于是省管局决定搞第二期,我参与进来,他们走了一人.我负责的部分效率提高了至少一个数量级以上.系统交付使用了,我拿到钱走人(本来就是火线加入,干完就走的,属于炒更类人物),但后来听说服务器端还是老毛病---每过几天要当机1次. 后来我自己负责的系统在研发阶段也开始大量用起存储过程,实施时也出现上述问题,处理逻辑未发现问题,慢慢去掉存储过程,当几乎全用SQL语句取代时,系统居然运转OK了.于是猜想问题出在存储过程上,系统调度上的资源消耗可能还大过所谓使用存储过程带来的性能提高.好笑的是,我专门对比测试却未发现使用存储过程带来的性能提高(处理时间).

我的经验(没有理论依据,所以心虚),如果能不用存储过程,打死也不用.

至于用普通 sql 取不到插入的 id 值,上面很多人已提到这个根本不是问题.

fisher 评论于 2006-01-11 09:24 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
在讨论这个问题的时候, 首先要弄清楚自己所在的角度. 如果你是一个Programmer, 你可能会从可维护性,接口,分布性等等问题来选择. 但是如果你是个DBA, 那么你首要的问题就是脱离前端的UI代码以及大部分的业务代码, 纯粹从维护数据库本身的角度来看待你所需要执行的东西.
任何问题走极端了, 就是哲学上的问题了. 结合实际, 才是有意义和有价值的应用.
说开了, 很多应用最后干脆都把存储过程名都改的乱七八糟了, 说明他根本就没有打算把这些SP开放给前端开发人员的了.
jimjiang 评论于 2006-01-11 09:42 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
看着这个古老的问题一再激起大家的兴趣，不仅也想参与进来。

诚然SP的选择与否属于一个技术问题，但讨论用SP好还是直接写SQL语句好，则必然成为一个哲学问题，或者一个方法论的问题。无数事例和先贤都告诉我们，单纯的说好与不好都是不可能长久正确的。技术在不断的进步，今天的观点和昨天的观点就有可能不同，所以说，哪个好？没有一个是绝对好的，完全要根据你的应用需求来选择。

同时，比考虑性能等更重要的是，应该咨询一下开发团队的伙伴们，多数人习惯或者乐于使用的方式，就是我们应该选择的方式，我们的目的是一起把程序作出来，让它按照客户的需求运行，而今天任何一个人单打独干什么都干不成，不是吗？

至于到底SP和SQL语句哪个更快，完全取决于是谁在写代码，我见过3K多SP的数据库，也见过一个SP都没有，但数据量比上一个系统更大的程序，都运行的非常好。

另外看到有提到数据库移植的问题，大家认真地回忆一下，我们做过的程序里，真是需要数据库移植，而且最终也确实进行了数据库移植的有多少？
Michael.zh 评论于 2006-01-11 10:03 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
不要老用移植来说是事儿, 以为直接写SQL就好移植了啊?
再说有价值的商业系统不会没事儿今天换SQLServer明天换Oracle后天换Postgres的. 数据库对商业系统存在绑定效能, 有时候上了贼船就下不来了!!
Sharper 评论于 2006-01-11 11:13 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
移植性不是要在运行的时候移植，而是对于一个产品化的东西来说，要的适应不同的环境，以减少客户的投资，扩大市场范围。也能减轻部署维护的难度。
小陆评论于 2006-01-11 11:18 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
全用存储过程很爽！！如果程序发布，要改就费事了！！

用SQL语句可以接收到新生成的记录的IDENTIFY值

我也常常用存储过程
gyf19 评论于 2006-01-11 12:02 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
程序开发是面向业务的
比如一个审核操作,可能操作10张表.用存储过程参数搞晕人（10个表的部分数据作为参数。！～～～）

我是特殊才用SP。（如利用SP 返回操作报错信息。）
mkimtaehee 评论于 2006-01-11 13:45 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
不过未来我还是要更多的往SP靠的
mkimtaehee 评论于 2006-01-11 13:47 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
[个人看法]
基本全部使用Store Procedure,事实上由于没有遇到平台移植的问题，所以对在移植上的感触不深. 除了移植性之外,实在想不到还有更好的理由不用SP的:－)
当然,在使用SP的时候也会带来一些困惑,比如在SP中总是会涉及到一些Business Rule的处理,但是从分层的角度来说SP应该属于Data Layer,不应该参与Business Rule.
当然事情不是说因为简单遵循分层的教条而感到困惑，而是因为当Business Layer和SP都涉及 Business Rule的处理时，可能会带来同样的RULE在Business Layer和SP中的处理没有及时同步的问题。
[个人看法]
~在思考中沉淀~ 评论于 2006-01-11 14:37 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
1.同样的功能,用 SP 性能肯定高!(预编译执行计划)

2.SP 修改很方便! 应用程序需要重新编译!

3.动态 SQL 是 SQL Inject 攻击之源!(要用安全的参数化SQL)

Microshaoft 评论于 2006-01-11 23:29 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
没有绝对的对,也没有绝对的错.个人认为根据实际项目情况决定.既然存在就有它的必有性.从技术的角度讲各有自己的优缺点,从业务或商业的角度讲,在一个项目里能用最快的周期和最少的后期维护成本,给项目创造最大的利润,哪种方式就是最合适的,(当然这里不一定是最好的)
[天道酬勤] 评论于 2006-01-12 09:13 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
看大家说的都不是Oracle环境吧,难道SQL Server对存储过程的支持这么差
Oracle中使用存储过程的好处几乎不用证明.
知道得越多知道的越少评论于 2006-01-12 09:35 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
扯淡，Oracle存储过程好处不用证明？
Oracle的存储过程比Sql Server也就多了个包的概念而已。
何况Sql Server2005似乎也引入了一个类似的概念。
風語者疾風评论于 2006-01-12 10:23 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
要知道 n 多 sp 和你 n 多对应的 .net 的数据访问方法的代码之间，sp 的参数列表就是一堆麻烦的接口，你需要维护它的。
　　-- 可以用工具生成
业务逻辑放在存储过程中不好
　　-- 存储过程是代替直接载代码中写SQL，业务逻辑该在哪里写还在哪里写

有些复杂的逻辑确实应该用SP封装一下！
Boler Guo 评论于 2006-01-12 11:33 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
表示谨慎的赞同，我曾写过一篇类似的post，结果被某些“牛人”bs，认为现在已经是ORM的时代了，我还在讨论这种小儿科的问题，非常幼稚，无奈，将其从首页撤下了，详见：http://rib06.cnblogs.com/archive/2005/10/12/253194.html
合金枪头评论于 2006-02-14 23:34 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
呵呵，真是，有点过时了~~
一颗草评论于 2006-03-10 16:15 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
结合使用,
梁广永评论于 2006-04-08 20:30 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
大家的讨论让我迷茫,我最近自己在做一个小系统,也在考虑这个问题,看来还是没有结果呀.我个人暂时这样认为,存储过程只是存储和读取数据的方法,业务逻辑应该还是应该在程序里实现,越是复杂越这样,要不然那个存储过程就太复杂麻烦了(也可能是我个人的存储过程技术不叼吧,就是觉得封装太复杂的逻辑写起来好大一堆).
shixl 评论于 2006-05-26 15:30 回复
# re: 也论该不该在项目中使用存储过程代替SQL语句
最近我在做公司项目中也发现了不少这样的问题，用ORM的NHibernate开发小型项目最实惠，可在类似于外汇系统这样的项目中用NHibernate就会在很多地方显得力不从心了，其一是因为其速度比用ADO.NET慢，其二是HQL还真的不是很成熟，当然也许是鄙人才疏学浅，有一些复杂的数据操作还是得结合存储过程才能实现。
　　我一位同事虽然代码写得不怎么漂亮，不过他在存储过程上还是很强的，一个存储过程就能把增删改及查询都囊括了，虽然维护性不是很好，包括存储过程，但只要能在限期之内把项目做完不就好了？
　　总之在被老板训了一顿后反思得出一个结论，写代码还是以快为主，至于写得好坏及分几层，最好是越简单越好，别把简单的事情复杂化了。想想国内及港澳地区对软件的要求还不像老美老日这么高呢，没办法，大家都浮燥了，程序员也得跟着浮燥才行。
　　一句话，能带来利润的工具就是好工具，能带来效益的代码就是好代码。

-------引:http://heroman.cnblogs.com/archive/2006/01/10/314631.aspx

留言