尴尬的存储过程

      最近在给一个已沉淀了多年的系统框架进行优化，发现大部分的基础业务（比如增删改）的实现都是通过存储过程来实现。这让我纠结了很久，看了下代码格式我猜应该都是使用了代码生成器。这无疑为系统的扩展留下了一个难以弥补的大坑。

      首先一定要搞明白为什么会有“存储过程”这个东西。如果我们使用程序访问数据库(比如 java 中的 jdbc、.net 中的 ado.net )， 正常情况是程序连接数据库服务器,然后向数据库服务器发送执行 SQL语句。 由于程序和数据库服务器之间的 SQL 执行过程其实就是网络通讯的过程，但网络通讯有时稳定性并不理想。如果一个业务操作要执行很多条 SQL 语句或执行一个 SELECT 查询时，遍历查询结果的时候又要执行其他sql语句进行其他操作的时候，在程序和数据库服务器之间就会频繁的进行网络交互，这样数据库服务器的压力会比较大,而且速度慢。这时候如果把这些业务逻辑写到一个存储过程,由于存储过程是运行在数据库服务器内的,这样只要程序向数据库服务器请求一次“运行某某存储过程”,剩下的就是在数据库服务器内部执行了,因此运行速度会快一些,而且并发压力会小一些。这是我们使用 “存储过程”这个东西的初衷。

      上述我想应该很清晰的能够明白为什么需要使用存储过程了，所以基于这种情况我们就不需要连最基础的增删改都使用存储过程了。

      另外,现在业界的共识是“尽可能的不用存储过程”,因为存储过程在不同数据库中的语法是不一样的,跨数据库移植很麻烦,还有存储过程很难和项目之间完美的进行源码版本管理,因此除了在一些极特殊的情况下,否则不要使用存储过程。