接上文：SQL Server 数据访问策略：即席SQL

　　存储过程是已编译的SQL代码，它可以被参数化以便重用。存储过程的封装性，安全性，性能等都是我们选择存储过程作为数据访问策略的理由，当然存储过程也不是完美无缺。

　　存储过程的封装性可以很好的隐蔽调用者不需要知道的执行细节，而且你可以根据需求变更重新编写存储过程，而不用担心会破坏任何客户端代码，换句话说，这意味着任何特性都可以改变，包括表结构，列名(当然返回的列名最好以别名，alias,形式出现)和编程方法，只要存储过程的名字以及参数不变，客户端不需要任何修改。我想这是我采用存储过程最重要的原因。

　　安全性，你可以针对SQL Server用户，对存储过程进行访问权限的设置，而不是授予用户对存储过程用到的资源进行访问权限设置;在实际工作中，你遇到过这样的情况吗?某些程序员或者用户修改不应该被修改的数据，删除了不该被删除的数据，之后跑到你这里来，我改怎么恢复过去?

　　我们通过下面的SQL 语句针对指定存储过程，将其执行权限授予指定用户， 这样的我们可以在具体表，列，行的基础上，更好管理安全性。

　　存储过程的参数可以使查询优化计划得到最大程度的利用，避免了检查语法，编译，生成机器代码，生成查询计划等，性能因此得到很大提升，同时客户端调用的只是存储过程的名字，在网络传输方面也要远比发送整段SQL代码要强。

　　相对于动态SQL的高耦合，对存储过程的修改不会或者很少对客户端产生影响。

　　存储过程有缺点吗？有！但绝对不是可一致性差，技术社区或者个人博客上在谈论存储过程缺点的时候，大部分人都在说存储过程可移植性差，这是因为他们将软件或者项目的业务逻辑封装在存储过程中了;针对存储过程的使用，我们应该扬长避短，SQL 使用来处理数据的，即SELECT, INSERT,DELETE,UPDATE操作，SQL在对逻辑运算方面远逊于编程语言，因为我们应该将业务逻辑放在中间层而不是DB层。

　　存储过程的缺点也是TSQL的缺点，TSQL是面向过程语言，是一种查询语言，因此它在程序分支或者条件控制方面(IF – ELSE,CASE)做的不好，而且效率很差。当存储过程中出现 IF ELSE的时候，个人建议可以考虑将其分为两个存储过程了。如果你不想在客户端调用的时候出现根据条件对调用哪个存储过程进行判断，你也可以创建另外一个存储过程在里面进行条件判断，确定哪个存储过程需要被执行(业务逻辑不知不觉又跑到存储过程里面了)。

　　另外存储过程在执行UPDATE操作的时候，不知道哪些列真正的被修改了，而是根据客户端闯过来的所有参数，将对应列都进行UPDATE，不够灵活。