Stored Procedure---Why?

处在地球一个极端的家伙说,"不用问为什么,就是应该用SP!"
处在另一个极端的家伙说:"不应该用SP!SP破坏了三层架构的设计,实际上把三层变成了两层".
SP的优势在什么地方?为什么微软要极力鼓吹凡事都用SP?
按照一般的理论,在程序分布位置图上,程序离数据越近其性能和数据完整性就越好.按照通常的说法,SP有如下好处:
1.存储过程是预先编译过的,是执行查询或者批处理的最快方法
2.在服务器上而不是桌面系统上执行程序可以极大地降低网络流量.
3.存储过程是模块化的,易于部署,代码也容易修改.
4.存储过程是数据库安全性的一个重要组成部分,如果所有的用户都是通过存储过程来访问数据的,那么,就可以禁止用户对表的直接,并控制对数据的访问.

对于后三点很好理解,可是对于第一点我始终有个疑惑.
一般的SQL语句也是会缓存执行计划的,不止存储过程会这样.存储过程存放在系统表syscomments中,当执行的时候先查看高速缓存中是否有执行计 划,如果没有则会从syscomments中找出对应的存储过程,编译得到执行计划扔到高速缓存中执行,当重启数据库服务器的时候执行计划就会消失,既然 这样一般的SQL语句跟存储过程有什么区别那?我自己测试的结果是两者是一样的,甚至一般的SQL还会快一些.不知道第一点是不是个美丽的谎言?
在我看来或许存储过程的优势在一条SQL语句没办法处理的时候,用存储过程可以把需要很多SQL语句配合在一起才能完成的任务封装在一个存储过程中,这样就可以减少与数据库的交互次数,性能会大大增加.
但是这样就会有一个问题,大多数时候需要与数据库发生多次交互的往往是复杂的业务逻辑,为了追求效率把多条SQL语句封装到一个存储过程中,势必把业务逻辑封装到存储过程中,在极端情况下,三层设计也就变成了两层,业务逻辑被封装到了数据访问层.
其实有些东西是要取得平衡的,没有绝对的做法,追求效率的同时也就放弃了灵活,不要跟我说用存储过程封装业务逻辑会更好维护之类的话,俺不信.
结合当前做的系统,我觉得在一些跟业务没有多大关系,只是用来显示数据并且需要与数据库发生多次交互的页面可以改成存储过程的方式,另外由于SQL Server没有rowNumber,如果主档页面要用到分页,也要改成存储过程的方式.还有一写树形结构,经常需要查找某个结点下的子结点,或者要根据 子结点获取父结点,这种情况下也可以用存储过程,根据结点和层级返回需要的结果.另外对于一些严重影响效率的业务逻辑也可以考虑封装成存储过程,不优美总 比不能用好得多,软件首先要Work嘛.