这篇随笔由于出差拖了很久，一时也没整理好该写些什么。在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并没什么冲突。虽然你可能说存储过程可以作为数据库内部资源实施安全策越。
