在公司的系统升级换代中，明确规定在数据库开发中不允许再使用存储过程了，以前的老一代系统中，很多复杂的业务逻辑都是存储过程写的，那为什么风光无限的存储过程不再被宠幸了呢？首先了解下什么是存储过程，它有什么好处，又有哪些劣势，为什么现在都不建议使用存储过程呢？
什么是存储过程
存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，预先编译好存储在数据库中，一次编译后永久有效，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。它是数据库中的一个重要对象。
存储过程的优点
1、可以减少程序在调用DB时候的信息传输量（其实减少的只有Request的时候）
2、存储过程是预先优化和预编译的，节省每次运行编译的时间，所以一般情况下认为存储过程的性能是优于sql语句的。
3、对调用者可以隐藏数据库的复杂性，将数据组装的过程封装。
4、参数化的存储过程可以防止SQL注入式攻击，而且可以将Grant、Deny以及Revoke权限应用于存储过程。
5、如果业务开发中，数据人员和业务代码人员是分离的，业务人员可以不用关心数据，直接调用存储过程，更加面向分层开发设计理念。
存储过程的缺点
1、存储过程这种“一次优化，多次使用”的策略节省了每次执行时候编译的时间，但也是该策略导致了一个致命的缺点：可能会使用错误的执行计划。
2、存储过程难以调试，虽然有些DB提供了调试功能，但是一般的账号根本就没有那种权限，更何况线上的数据库不可能会给你调试权限的，再进一步就算能调试效果也比程序的调试效果要差很多。
3、可移植性差，当碰到切换数据种类的时候，存储过程基本就会歇菜。
4、如果业务数据模型有变动，存储过程必须跟着业务代码一起更改，如果是大型项目，这种改动是空前的，是要命的。
为什么不建议使用存储过程
以上存储过程的优缺点，表面看来存储过程的优势还是不少的，这也说明为什么老一辈程序员有很多喜欢写存储过程。但随着软件行业业务日益复杂化，存储过程现在复杂业务及大流量面前其实有点有心无力。
1、采用存储过程操作数据在网络数据量传输上确实比直接使用sql语句要少很多，但这通常并不是操作数据系统性能的瓶颈，在一次操作数据的过程中，假设用时100毫秒，采用存储过程节省数据传输时间0.5毫秒（就算是5毫秒），我觉得这点时间基本可以忽略。
2、存储过程是只优化一次的，这有时候恰恰是个缺陷。有的时候随着数据量的增加或者数据结构的变化，原来存储过程选择的执行计划也许并不是最优的了，所以这个时候需要手动干预或者重新编译了，而什么时候执行计划不是最优的了这个平衡点，预先无法知晓，这就导致了有些应用突然会变慢，程序员处于懵逼的状态。
3、存储过程确实可以对调用方隐藏数据库的细节，但是这种业务代码人员和数据库设计人员是两个团队的情况又有多少呢，如果真是两个团队，那业务就需要两个团队来理解和沟通，我想沟通的成本也一定很高，而且分歧更容易产生。
我自己是有切身感受的，在接手的旧系统，令我头疼的不是业务，很多重要的业务逻辑都写在上千行的存储过程，关键还没有调试的权限，在生产上也不能调试啊，出现个报错，都不知道如何怎么下手了。尤其是当有业务改动上线时，必须要停掉所以相关的存储过程重新编译，总有一些莫名其妙的问题出现，相当烦躁！
我认为数据库就应该做存储相关的事情，这也是它最擅长的事。现在的互联网的大流量冲击下，如果把业务处理及计算放在数据库上，数据库的负载压力会特别大，肯定是顶不住的。再说了，现在搞的都是分布式集群，分布式数据库，存储过程已经不能胜任了。