减少存储过程封装业务逻辑-web开发与传统软件开发的思维模式不同

本篇文章讨论并不是：不要使用存储过程,因为有些事情还是要存储过程来完成,不可能不用。而是关于："业务逻辑是不是要封装在存储过程中实现，这样子php、java等就是调用存储过程"。

业务逻辑，通俗说就是：比如要取数据的操作，取出会员编号为x的数据，原来我们一般是封装成函数，或者直接编写sql语句查询。现在是交给数据库的存储过程去完成。

在互联网开发中，把业务逻辑封装在存储过程来实现的做法比较少，从我以前呆的都是互联网公司来看，确实很少使用存储过程实现业务逻辑。存储过程能不用尽量不用,原则是:业务逻辑不要封装在数据库里面(数据库去进行逻辑判断业务)。把业务逻辑要交给应用程序处理。这样可以减少数据库资源消耗。人员也难以招聘，因为既懂存储过程，又懂业务的人少。使用困难。大量业务逻辑封装在存储过程中，造成后面根本就不能动了。动a影响b。以后业务逻辑很难剥离出来。增加以后维护困难。

其实，很多真正提高效率的终极办法是使用缓存而不是在数据库中运算，靠数据库预编译或减少网络流量那点优化就可以，那说明性能要求原本不高。可以去了解google，亚马逊，淘宝网，新浪等是如何做的。像电信他们那样子大量提高硬件治标不治本，而是用分布式代替，就像人，单个人总再强总是存在极限的。所以使用存储过程速度更快，那点速度的提升其实微不足道。根本无法解决本质问题。

企业级内部系统，可以使用。互联网一定要少用。这是经验。经历过教训的。因为互联网应用是一个对所有人都开放访问的系统(越多人访问商业价值越大)，无法预估未来的用户量，数据量的。以后要扩展就非常麻烦了。

随着海量的数据增长,高并发的系统,数据库慢慢转化为仅仅作为数据的容器. 如果你的数据库存在瓶颈,存储器,触发器这些都没用了.

从web层扩展是很容易的.所以把计算留给web层吧.

阿里、淘宝的大牛dba们强烈建议在mysql库中，尽量不要使用存储过程，不易维护，出问题跟踪十分麻烦，从管理的角度我很认同这样的观点，从实现上来时存储过程也是具备一定的优势的，看场景选用，能不用则不用为妥。需要先预编译，在实际中不是经常用到，当然还要看是什么样的项目来决定.

分析：数据库用来做他擅长的事情，存储数据。把数据库当成一个存储数据的地方。计算的事情尽量交给程序应用层来处理。跟现实中的哲学：不要让大脑干其不擅长的事情。大脑适合干脑力活想事情，你偏偏安排到去做体力：拼头力气大小。