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

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

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

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

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

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

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

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

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

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

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