他认为程序中几乎不应该出现sql 语句, 所有的访问数据库的动作, 都应封装成存储过程. 而我不喜欢存储过程, 不到万不得已, 我不会使用存储过程.
我的想法:
<1>效率.
<1.1>先考虑简单sql 语句, 所谓简单, 比如只有一个 select/update/insert/delete 语句, 对简单sql 语句来说, 与存储过程的差异在哪里呢, 存储过程只是预先编译过了, 也就是说, sql语句的执行时间=编译时间+ 执行时间, 而存储过程只有执行时间, 没有编译时间. 而两者的执行时间应该是一样的, 对于简单sql 语句来说, 编译时间非常小, 可以忽略不计, 虽然没有确切的数据, 不过我认为我的这个推断应该没有什么问题. 也就是说, 从效率上讲, 简单sql 语句与存储过程没有什么区别. 我用过各种各样的简单sql语句测试, 这其中也包括链接十几张表的复杂查询, 执行时间跟存储过程没什么差异.
<1.2>复杂sql语句段. 要声明一下, 我认为很长, 譬如几十句, 甚至上百句的sql 段根本不应该存在. 因为比较长的sql语句段一定会包含许多"逻辑" 处理, 而不是"数据" 处理, 举个简单的例子, 像left 这样的字串操作函数, 我觉得根本不应该出现在sql 语句中. --------在服务器中, 数据库服务器是压力最大的服务器, 也是最关键的服务器, web 服务器相对来说压力就小得多, 同等的工作, 应该优先考虑由web服务器来负责, 而不应该转嫁给数据库服务器. 另外, sql 语句虽然经过编译, 但是在类似left 这样的函数处理能力上, 比由C# 这样的高级语言的处理能力还是差得多(这一点不需要证明吧...) , 所以, 我认为所有的逻辑判断, 业务处理, 都应该由高级语言处理, 而sql 语句只处理数据, 这样也可以保证将数据库服务器的压力降到最小. 这一观念的推论, 就可以得出, 长长的sql 段是要不得的, 虽然存储过程擅长sql段, 但是我的程序会保证总是提交给服务器简单sql 语句.
<２>安全性.
提到存储过程, 就会常常提到它对用户的分隔能力, 可是在我参与过的三四个大型项目来看, 这种能力几乎毫无用处, 至少在我所参与的ERP 项目中, 它是毫无用处. 因为最终用户根本不会, 也无需, 也不可能去了解数据库层的东西, 他们只是要求打开一个页面, 可以展示一个报表, 或操作数据, 或完成某个流程等, 实际上, 即使使用存储过程, 在程序中也总是以某一个高权限用户去访问所有的存储过程.
<３>可扩展性.
从这个角度来说, 存储过程就处于完全没有竞争力的地步了. 一个页面很可能会发展变化, 但是每次升级都改动存储过程显然是一件危险的事, 事实上, 一个存储过程一旦写完投入使用, 就很少有人敢去改它. 而sql 语句则可以任意的升级,变化.
<４>可管理性.
由于任何一个项目在其漫长的生命期中都很难预测它到底会膨胀到多大, 所以存储过程的数目也会急剧地增加, 几百个存储过程是很稀松平常的事, 大型项目的存储过程达到几千个一点也不夸张, 如许多的存储过程, 要管理并记清楚每一个存储过程所完成的工作, 实在不是一件容易的事. 尤其是, 写这个存储过程的人离职后, 新来的人多半会被大量的存储过程难倒.
<５>我个人认为使用存储过程很麻烦, 远不如sql语句来得方便.
<６>借助于将表映射成类, 可以很好的支持表结构改变, 这主要是针对从零开始开发, 因为在第一次设计中, 不可能将数据库的结构设计得一次到位, 如果到了后期修改表结构, 所有的旧引用都是运行时错误, 而类型化的sql 语句则会变成编译时错误, 只要全项目替换一下就可以了.
因此, 我的结论是,
<原则1> 只有在很复杂, 需要大量的sql语句时, 才应使用存储过程.
<原则2> 应把所有逻辑处理转移到web服务器, 除极少数特殊情况外, 不应使用sql段.
根据这两个原则, 就很少会有使用存储过程的机会了.
但是, 由于对存储过程缺乏更深入的理解, 所以我对上想法也并没有太大的把握 , 在网上查了不少东西, 也罕有有用的文章, 多半是隔靴搔痒, 或是给新人看的, 或是语焉不详, 一笔带过, 所以就先贴在这儿, 大家在扔砖头之余 , 希望能详细地谈谈这个问题, 也好有个确定的答案.
阅读(745) | 评论(0) | 转发(0) |
