存储过程——优或劣

看了一篇文章，谈论该不该在项目中使用存储过程代替SQL语句。看后有一些感想，因为最近工作接触到一个系统，业务过程几乎完全是用存储过程实现的。随着系统的不断发展，新的需求逐渐难以支持。这个原因当然很复杂，即使不使用存储过程，可能也有同样的问题。但是既然谈到具体技术上，就来看一下一个主要以存储过程实现的系统到底有哪些问题。

存储过程和嵌入程序中的SQL哪个更好，要用一种合理的比较方式来比，不能拿写的好的存储过程和写的烂的程序比，当然也不能拿写的烂的存储过程和写的好的程序比。我们先假设开发人员具有同样水平，项目组具有同样的组织协调能力，他们写出的存储过程和代码具有同样的质量，都已经根据产品的具体情况做出了最优的选择。

很多人这样认为：存储过程运行在最靠近数据的地方，最大限度减少了业务处理的环节，因此具有最高的运行效率。对于一个独立的程序片断来说确实如此。但是当一个软件规模逐渐增大，业务逻辑逐渐变得复杂以后，这一点差距已经不会对运行效率造成决定性的影响了。这时候，影响程序效率的因素变的更加复杂，比如：系统对于并发任务的处理是否合理、是否具有分布式的能力、是否可以将常用的数据缓存……这些能力靠存储过程来实现是非常难的，甚至是不可能的。一旦采用了存储过程，在程序漫长的生命周期中，要提高程序的运行效率就只有一个办法了：增加硬件投资。但是这个办法不一定有很好的效果，因为再好的硬件条件也无法弥补一些根本的缺陷。

软件开发发展到现在，总的来说有个规律，就是要让开发者越来越少的考虑技术问题，越来越接近客户的业务思维。现代的软件开发，已经越来越接近这样的方式：研究客户的需求，为业务建立模型，分析系统的外部和内部需求，以最接近业务模型的方式建立软件系统模型。这样的方式建立的系统才能最好的满足客户的需要，同时也能较好的适应需求的发展。

如果采用存储过程作为建立业务层的形式，结果就是回到“排列需求——数据库设计——界面设计——编码——测试”的道路上。这样当然是可以把系统做出来的。系统部署了，这只是他生命周期的开始，一切才刚开始。存储过程不仅实现了当前的业务需求，也建立了一系列的API。在漫长维护过程中，维护人员在这些API的基础上实现新的需求、修改这些API的错误。如果发现某个API“似乎”错了，或者不满足新的业务需求，没有人敢修改他们，最好的办法是：再加一个新的API。存储过程的数量越来越多，越来越难以命名——函数难命名不是编码的问题，而是设计的问题。于是，在项目运行两年以后，还是难以形成一个优质稳定的业务开发平台，人们还在探究数据表、字段、VARCHAR500、1403 data not found……

说到这里我也许应该得出结论，存储过程是不好的。可以这么说：用存储过程实现主要业务逻辑不是一个好办法。但是这个东西既然被创造出来，一定也有他适用的地方。

如果我有这样的需求：数据库中有大量的实时运行数据，需要定期把这些数据进行简单的行列归整，放到另外一个数据库中做分析统计之用。在这种情况下我首选存储过程。存储过程应该处理“数据”，而不要处理“业务”。并且在这种情况下存储过程极大的减少了IO消耗，真正的体现了他的效率优势。