聊起存储过程的优缺点一贯的风格是旱的旱死涝的涝死，各执一词。
就我们正方观点来看，存储过程有着‘绝对’的优势：
1. 首先存储过程可以减少它的网络通信量，相对于复杂的逻辑来讲，它既可以无需过多的笔墨对查询数据进行总（联表查询） 分（逻辑处理）总（数据整合）的繁杂操作，在输出结果之前即可实现相关数据的整合处理。其性能绝对比一条一条的调用SQL语句要高的多。且笔落则数据出。
2. 它的逻辑处理清晰简单，存储过程说白了就是 一堆SQL 的合并。中间加了点逻辑控制。逻辑处理在你考虑几十行代码最优解的时候，可能别人已经通过简单的十几行存储过程解决了。且充分利用了db本身的优势，执行速度更快。在存储过程创建的时候，数据库已经对其进行了一次解析和优化。其次，存储过程一旦执行，在内存中就会保留一份这个存储过程，这样下次再执行同样的存储过程时，可以从内存中直接调用。它是个不容易犯错，且让个人能力差距缩小，编码速度提升的可行办法。
3.它具有超强的适应性，且开发人员承接更为容易。由于存储过程对数据库的访问是通过存储过程来进行的，因此数据库开发人员可以在不改动存储过程接口的情况下对数据库进行任何改动，而这些改动不会对应用程序造成影响。同样在接手别人代码的时候，不过是接手一个具备功能的'轮子'，其本身只是一堆sql语句，谈不上思想的碰撞，更不会因为思路不同导致不理解或者难以理解的问题。
4.它甚至可以作为简易的中台使用，数据以及适当的逻辑处理提交通过存储过程，其余的由程序处理，分布式工作。
5.它可以通过传入参数不同实现动态sql语句去查询不同的表数据，对于不同的表但是逻辑基本相同的数据需求可以通过传输不同的参数实现接口的合并。使得逻辑进一步精简和清晰化。起码这一点应该受到python相关的同仁的认同（我以为）。
原文理解是：使用存储过程使您能够增强对执行计划的重复使用，由此可以通过使用远程过程调用 (RPC) 处理服务器上的存储过程而提高性能。RPC 封装参数和调用服务器端过程的方式使引擎能够轻松地找到匹配的执行计划，并只需插入更新的参数值。
6.可维护性高（相对的），更新存储过程通常比更改、测试以及重新部署程序集需要较少的时间和精力。ps : 当你的存储过程写满了整个数据库，即使你有很好的命名和备注，也逃不开在'乱花'中取一支的命运。不过更改起来的舒适度十分。
7. 更好的版本控制。 看你存储过程后面的标识就知道了。
当然，我们可爱又迷人的反派角色肯定是要上场的。存储过程也有着它‘天大’的缺陷：
ps : 以至于我同事十分之反感用此方法去实现任何功能。 其最灵魂的拷问就是： 你能学到个啥？
1. 运行速度。 因为存储过程终究还是需要整合这些sql，它需要设计检查权限等，比直接执行sql花费更多。尽管它省略了预编译的过程，但是大多数高级的数据库系统都有statement cache的，所以编译sql的花费没什么影响。所以对于很简单的sql，存储过程没有什么优势。甚至有一点点小扣分（当然，几乎无视。）
2. 网络负荷：如果在存储过程中没有多次数据交互，那么实际上网络传输量和直接sql是一样的。
3. 团队开发：很遗憾，比起成熟的IDE，没有什么很好存储过程的IDE工具来支持，也就是说，这些必须手工完成。（商机哦）
4. 安全机制：对于传统的C/S结构，连接数据库的用户可以不同，所以安全机制有用；但是在web的三层架构中，数据库用户不是给用户用的，所以基本上，只有一个用户，拥有所有权限（最多还有一个开发用户）。这个时候，安全机制有点多余。
5. 用户满意：实际上这个只是要将访问数据库的接口统一，是用存储过程，还是EJB，没太大关系，也就是说，在三层结构中，单独设计出一个数据访问层，同样能实现这个目标。
6. 开发调试：一样由于IDE的问题，存储过程的开发调试要比一般程序困难（老版本DB2还只能用C写存储过程，更是一个灾难）。
7.移植性：算了，这个不用提，反正一般的应用总是绑定某个数据库的，不然就无法靠优化数据库访问来提高性能了。
8. 维护性：的确，存储过程有些时候比程序容易维护，这是因为可以实时更新DB端的存储过程，但是在3层结构下，更新server端的数据访问层一样能实现这个目标，可惜现在很多平台不支持实时更新而已。
反正综上所述，于我听起来就是，存储过程没有更好，不熟练的话，维护更麻烦。emm，不过博主的一句话我认同：
存储过程的使用不能有死规定（全用，或全不用）。现在，我认为的原则是：所有数据访问在应用层封装为数据访问层，在那里，如果SQL简单的话，直接用SQL；如果SQL复杂，或者数据交互多且中间数据最后不会用到，使用存储过程 。
