文章标题:存储过程——天使还是魔鬼 | 作者:小陆 |
URL:http://www.cnblogs.com/lane_cn/archive/2006/01/11/315593.html | |
|
|
看了Heroman的一篇文章,谈论该不该在项目中使用存储过程代替SQL语句。看后有一些感想,因为最近工作接触到一个系统,业务过程几乎完全是用存储过程实现的。随着系统的不断发展,新的需求逐渐难以支持。这个原因当然很复杂,即使不使用存储过程,可能也有同样的问题。但是既然谈到具体技术上,就来看一下一个主要以存储过程实现的系统到底有哪些问题。 存储过程和嵌入程序中的SQL哪个更好,要用一种合理的比较方式来比,不能拿写的好的存储过程和写的烂的程序比,当然也不能拿写的烂的存储过程和写的好的程序比。我们先假设开发人员具有同样水平,项目组具有同样的组织协调能力,他们写出的存储过程和代码具有同样的质量,都已经根据产品的具体情况做出了最优的选择。 很多人这样认为:存储过程运行在最靠近数据的地方,最大限度减少了业务处理的环节,因此具有最高的运行效率。对于一个独立的程序片断来说确实如此。但是当一个软件规模逐渐增大,业务逻辑逐渐变得复杂以后,这一点差距已经不会对运行效率造成决定性的影响了。这时候,影响程序效率的因素变的更加复杂,比如:系统对于并发任务的处理是否合理、是否具有分布式的能力、是否可以将常用的数据缓存……这些能力靠存储过程来实现是非常难的,甚至是不可能的。一旦采用了存储过程,在程序漫长的生命周期中,要提高程序的运行效率就只有一个办法了:增加硬件投资。但是这个办法不一定有很好的效果,因为再好的硬件条件也无法弥补一些根本的缺陷。 软件开发发展到现在,总的来说有个规律,就是要让开发者越来越少的考虑技术问题,越来越接近客户的业务思维。现代的软件开发,已经越来越接近这样的方式:研究客户的需求,为业务建立模型,分析系统的外部和内部需求,以最接近业务模型的方式建立软件系统模型。这样的方式建立的系统才能最好的满足客户的需要,同时也能较好的适应需求的发展。 如果采用存储过程作为建立业务层的形式,结果就是回到“排列需求——数据库设计——界面设计——编码——测试”的道路上。这样当然是可以把系统做出来的。系统部署了,这只是他生命周期的开始,一切才刚开始。存储过程不仅实现了当前的业务需求,也建立了一系列的API。在漫长维护过程中,维护人员在这些API的基础上实现新的需求、修改这些API的错误。如果发现某个API“似乎”错了,或者不满足新的业务需求,没有人敢修改他们,最好的办法是:再加一个新的API。存储过程的数量越来越多,越来越难以命名——函数难命名不是编码的问题,而是设计的问题。于是,在项目运行两年以后,还是难以形成一个优质稳定的业务开发平台,人们还在探究数据表、字段、VARCHAR500、1403 data not found…… 说到这里我也许应该得出结论,存储过程是不好的。可以这么说:用存储过程实现主要业务逻辑不是一个好办法。但是这个东西既然被创造出来,一定也有他适用的地方。 如果我有这样的需求:数据库中有大量的实时运行数据,需要定期把这些数据进行简单的行列归整,放到另外一个数据库中做分析统计之用。在这种情况下我首选存储过程。存储过程应该处理“数据”,而不要处理“业务”。并且在这种情况下存储过程极大的减少了IO消耗,真正的体现了他的效率优势。 |
![](https://img2024.cnblogs.com/blog/35695/202403/35695-20240328092537879-1189167464.jpg)