该不该在项目中使用存储过程代替SQL语句(二)

JerryXia 发表于 , 阅读 (2,281)

看着这个古老的问题一再激起大家的兴趣,不仅也想参与进来。

诚然SP的选择与否属于一个技术问题,但讨论用SP好还是直接写SQL语句好,则必然成为一个哲学问题,或者一个方法论的问题。无数事例和先贤都告诉我们,单纯的说好与不好都是不可能长久正确的。技术在不断的进步,今天的观点和昨天的观点就有可能不同,所以说,哪个好?没有一个是绝对好的,完全要根据你的应用需求来选择。

存储过程最大的好处是什么,就是性能。还有就是复杂的处理情况。

因此,如果不是为了考虑性能,一般情况下我不喜欢用存储过程。因为存储过程带来的麻烦问题也太多了。就如前面说的CRUD,我们的程序开发是在前进,程序开发是面向业务的,而不应该面向数据库。存储过程让很多的东西都回到了数据库,程序的修改或是什么的,都会涉及数据库,移植性也差。但如果说系统的对性能的要求很高,而且数据量也确实非常大,那么在没有替代方案的情况下,应该是选择存储过程的。

与很多人认为的相反:存储过程的效率是最低的。

初看起来,存储过程最接近数据存储的位置,应该具有最高的效率。但是,当程序的规模大到一定程度后,复杂到一定程度后,决定效率的就不再是距离,而是分布式性能、并发处理性能、数据缓存、任务调度的合理性、离线处理的性能……这些性能靠存储过程都是很难实现的。

一个主要依靠存储过程实现其业务逻辑的系统,发展到最后很可能是个数据库不堪重负,维护者感到无可奈何的系统。对于一个规模较大的系统,不要过多的使用存储过程,当成一个database。gateway是可以的,不要让他依赖任何业务逻辑。

同时,比考虑性能等更重要的是,应该咨询一下开发团队的伙伴们,多数人习惯或者乐于使用的方式,就是我们应该选择的方式,我们的目的是一起把程序作出来,让它按照客户的需求运行,而今天任何一个人单打独干什么都干不成,不是吗?

至于到底SP和SQL语句哪个更快,完全取决于是谁在写代码,我见过3K多SP的数据库,也见过一个SP都没有,但数据量比上一个系统更大的程序,都运行的非常好。

另外看到有提到数据库移植的问题,大家认真地回忆一下,我们做过的程序里,真是需要数据库移植,而且最终也确实进行了数据库移植的有多少?

添加新评论