转存储过程优劣

观点

1.经过ORM工具，同样能够作到由于创建屡次链接，执行SQL而使用存储过程达到减小链接获取的过程。0.5~1s

2.2005年之前，以数据为中心的方案，其实很差的就是可移值性，以及集群环境下的SP执行。适用场景是复杂的报表需求，全表计算，避免把表数据所有加载到应用服务器中计算

3.领域驱运开发DDD的思路就是让业务逻辑层变得强壮，反而典型就是存储过程这样的事务性脚本开发模式。在存储过程当中包含了太多的业务逻辑。UI层只须要返回调用的结果。没有中间层。

 

 

 

 

这篇随笔因为出差拖了好久，一时也没整理好该写些什么。在google搜了下“存储过程 优劣”关键字，资料并很少，出现了一篇关于来至51cto的关于存储过程的优缺点的文章，具体这里也不指出了。看见文章中对存储过程的几个辩解，我的不敢苟同，我的已经很仔细的看了文章的时间是2011年，若是在更前写年成的话，我的以为彻底可以理解。因此有了这篇，存储过程的一些传言。

1：存储过程只在创造时进行编译，之后每次执行存储过程都不需再从新编译，而通常SQL 语句每执行一次就编译一次,因此使用存储过程可提升数据库执行速度。

在sql server 2000版本，这个观点没错，倒是如此。可是在sql server2005文档中很清晰的写到 sql server2005的执行任何sql，关系引擎会首先查看缓存，判断是有有其执行计划。若是有，则将会重用该执行计划，以减小从新编译sql语句生成执行计划的影响。包括Oracle也是这么作的，因此在咱们常见的数据库中不存在这所谓的问题。

2：当对数据库进行复杂操做时(如对多个表进行Update,Insert,Query,Delete 时)，可将此复杂操做用存储过程封装起来与数据库提供的事务处理结合一块儿使用。这些操做，若是用程序来完成，就变成了一条条的SQL语句，可能要屡次链接数据库。而换成存储，只须要链接一次数据库就能够了。

这个问题在前面的架构设计-数据访问层简述中说过，DBA老是告诉咱们减小数据库链接次数，这是彻底无争议的，我表述很赞同。可是必定是存储过程的优点?或者说除了存储过程就没其余方式?在架构设计-数据访问层简述中介绍了来自Martin Fowler《P of EAA》的UOW(工做单元)模式，定义为工做单元记录在业务事务过程当中对数据库有影响的全部变化。操做结束后，做为一种结果，工做单元了解全部须要对数据库作的改变。其主旨是在内存中创建一个和数据仓库，维护变化的对象，业务对象变化跟踪，在业务操做完成一次性提交到数据存储介质，提供业务事务。这模式已经在咱们常见的ORM(EntityFramework，Nhibernate等)中很好的支持了，或许这么说这也是ORM框架的一个重要特征。在好比微软的DataSet也支持，批量更新。

3:存储过程能够重复使用，可减小数据库开发人员的工做量。

在项目中咱们糜烂的重复代码仅仅在于数据层?更多或许在于业务逻辑的处理，复杂的条件判断，数据操做的组合。存储过程是由开发人员开发，仍是数据库开发人员?每一个公司的数据库开发人员就仅仅那几个吧，我见过的公司。存储过程是否包含业务规则?若是有的话，业务的不停变化，会不会不停的修改关系模型，修改存储过程，sql的编写和调试虽然如今工具备必定的支持，可是我以为没有开发语言这么智能方便吧，至少我还没看见。若是没有至少简单的查询语句，那和普通的sql有什么差异?减小开发量为何不选择ORM之类的动态sql，采用彻底的对象模型开发，只在少部分ORM失效的业务返璞归真。

4：若是把全部的数据逻辑都放在存储过程当中，那么asp.net只须要负责界面的显示功能，出错的可能性最大就是在存储过程。通常状况下就是这样。升级、维护方便。

这句话更离谱。逻辑放在存储过程，便于维护，我也进入过这样的公司参与过这样的项目，因为刚开始新员工，不能全盘否认，我看见的是恼人的存储过程，恼人是sql，没看过那个开发人员喜欢sql，特别在每次项目需求变动的时候。后来慢慢接受ddd模式，把业务从sql中挣脱出来。asp.net只须要负责界面的显示功能，逻辑层次未免太简单了，我猜想这应是事务性脚本开发模式，其优劣点在架构设计-业务逻辑层简述中说过，只能实用于简单小型的项目。在加上可移植性差，若是你的客户须要数据库的升级，sql server到Oracle会怎么样。

5：安全性高，可设定只有某此用户才具备对指定存储过程的使用权。

安全对于项目来讲不只仅在于数据库，而应是分布于咱们系统各处。安全关注点应该从表现层到数据库各层之间都应该有处理。通常比较灵活有效基于角色(域)安全和数据库安全，物理服务器安全共同使用，这和不适用存储过程，使用sql并没什么冲突。虽然你可能说存储过程能够做为数据库内部资源实施安全策越。

 

6：还有些：存储过程能够防止sql注入

这个是固然的，毫无争议。由于用的是参数化方式，你不能随意拼接字符串，参数化方式可以帮助咱们防止大多数的sql注入。在ado.net中为咱们提供了很好的参数化支持，使用sql咱们一样能够作到，再加上一切开源的安全组件的过滤。

最后存储过程并非万恶的，他有他的应用场景，对于复杂逻辑如报表的场景，我会坚决果断的放弃ORM，选择它，由于orm不能知足这种复杂查询，可是准确的说我选择的是大量的T-SQL或者是P-SQL，存储过程就是一堆sql子程序的固定格式。我以为能够彻底采用ibatis.net方式的xml配置，更爽些。选择存储过程是因为复杂查询业务，我相信你们也不会为了一些复杂的统计把全表数据加载到内存吧。存储过程开发技术流行与2005前数据为中心的开发模式，在如今的模式，工具，技术下显得有些苍老，但并非一无可取。你也能够彻底采用基于存储过程的开发模式开发出很好的系统。