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

存储过程的好外,我就不多说了,想必各位都已了然于胸。当然,存储过程也有不少坏处:

• 当存储过程数量越来越多的时候,在众多存储过程中找到想要修改的存储过程是一件麻烦的事.
• 如果用嵌入式SQL语句,可以在修改代码时,顺便就修改了数据库操作语句,方便

针对这两个所谓的缺点,我提出我的一些看法:

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

最常见的是,在实际运用中,为了减少DATASET数据集的大小和提高性能,通常我们只SELECT当前需要的字段,但是,随着发展,你可以需要其他字段,这时,如果用嵌入SQL,就要修改SQL语句,编译,再写上绑定该字段的表达式,但是,如果用存储过程,你只要绑定表达式,然后给存储过程中加上这个字段名就可以了。

再如,如果用STRING来拼贴SQL的INSERT语句,那很可能是这样拼

string strSql=”insert into table (id,username,password,address) values(“+Id.ToString()+”,”+UserName…

这样拼贴,多加个字段时,一花眼,就拼贴错了,如果用存储过程,你顶多用

SqlParameter myPara = new SqlParameter(“@field5″,Field5);

再在存储过程里加上这个输入参数就可以了,和修改一下SQL语句就行了,SQL还会在修改过程中帮你检查语法,后者显然比前者用那么多+号与双引号拼贴出错的几率小多了

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