MySQL：尽量不要用存储过程封装业务逻辑

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

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

在一家公司，老板请工商银行的一个技术总监(老板自己说是总监，具体不知道)来跟我们聊聊，我猜是老板的朋友，相互交流一下。那个技术总监跟我聊的时候，让我们把存储过程发给他，他回去看看。打住。听到这个我就感觉很诧异，当时我心里就想，我们做web开发很少使用存储过程来实现业务逻辑的，他让我发存储过程，确实无法发哦。只能说没有。

有一点我比较肯定，在互联网开发中，把业务逻辑封装在存储过程来实现的做法比较少，从我以前呆的都是互联网公司来看，确实很少使用存储过程实现业务逻辑。

因为在此之前，我看过支付宝数据库架构师冯大辉的经验分(http://www.infoq.com/cn/presentations/fengdahui-mysql),他特意提到尽量不要用存储过程来实现业务逻辑。当时我把观点记录下来了：

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

我记得当时他还特意举例说了上海一家游戏公司用存储过程来封装业务逻辑，后来改业务逻辑非常麻烦(我估计是既懂程序又懂存储过程的确实少)。

于是我去搜索资料，我发现一个情况，在电信、银行业、金融方面以及国企都普遍使用存储过程来熟悉业务逻辑，但是这种经验放到互联网未必是对的。

看知乎上面这篇文章如下：

http://www.zhihu.com/question/19920716

================================

公司技术总监偏爱用存储过程来实现所有业务逻辑，请问这有什么弊端吗？

我们有企业内部应用和互联网应用，他都主张使用存储过程来实现所有业务逻辑，并用他参与过的广东省移动省级项目中使用存储过程实现用户登录等例子来说服我们。现在数据库用的是SQL SERVER2005

============================

利弊是相对的，使用存储过程来实现不一定是什么“滔天大罪”，这完全取决于系统的规模，扩展性以及产品的发展方向。
通常情况来说，把业务逻辑写到存储过程中不利于系统分层设计和维护，更不利于数据库的迁移（当然没有谁总想着换个数据库玩儿玩儿），这么做的原因很可能是他认为可以提高性能（存储过程的性能确实优于SQL访问的性能），不过为了解决性能问题有很多种方案，这种方式可能会差一些。

============================

上面这里有个网友就说他们技术经理主张使用存储过程来实现业务逻辑。我现在发现一点，从国企，银行里面来的，都是非常钟爱存储过程来实现业务逻辑的。这也是因为没经历过互联网公司情况所致。

使用存储过程，他们提的最大优点是和理由是：执行速度更快。不需要经过数据库服务器解析，提高执行速度，因为预先编译了。sql注入完全屏蔽非常安全(安全可以有他方案，更多是一种整体取舍，而不是单纯一方面考虑)

银行业普遍使用存储过程封装业务逻辑，我在搜索ibatis的时候，发现一个资料，来源为 http://baike.baidu.com/link?url=-suKmDp850my0GFevZvApmW09t_dYIzx5hW-KUGNPn5fyeojVmNHy-Pv4N2pu6CC

提到如下内容：

========================================
在笔者的系统咨询工作过程中，常常遇到以下情况：
1． 系统的部分或全部数据来自现有数据库，处于安全考虑，只对开发团队提供几条Select SQL（或存储过程）以获取所需数据，具体的表结构不予公开。
2． 开发规范中要求，所有牵涉到业务逻辑部分的数据库操作，必须在数据库层由存储过程实现（就笔者工作所面向的金融行业而言，工商银行、中国银行、交通银行，都在开发规范中严格指定）
3． 系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标。

===========================================

有很多技术会鄙视：程序员，为什不用存储过程来封装业务逻辑，我看到一个网友如下批评那些不使用存储过程封装业务逻辑的程序员：

这种思路很普遍，导致很多时候，滥用！
我就遇到一个问题，从一堆数据中找出满足条件的某些数据，把所有的数据从数据库读取到客户端，然后计算，筛选数据！我问他为什么不考虑存储过程，为什么不在数据库端筛选数据？系统工程师回答的是，存储过程对程序的移植性不好（如果换了数据库，就得重新实现一套，起始，很多数据库的sql语法都不一样，换了数据库，难道应用程序就不重新写sql语句了？如果完全适应SQL标准的sql语句，那就无法发挥出数据库自身的优势了），还有就是代码维护起来不方便，看不到存储过程的代码，难于找出错误！哎。。。无语啊！

================================

其实，我非常认同这个系统工程师的看法，使用存储过程移植性不好。确实对于开发人员来说，难以调试bug，定位错误。之前淘宝网就是遇到这种问题带多。当然让你们dba去找错误，开发人员就没法做。那么都变成dba来实现业务逻辑或者是程序员都要学习存储过程编程。

对于这句：换了数据库，难道应用程序就不重新写sql语句了？

我的看法：不是有pdo之类的数据库透明层来解决吗？可以屏蔽对具体mysql还是oracle数据库的依赖。

±----------------------------------------------------------------

我写本篇文章表达两个主要观点(也方便以后与人讨论)

±----------------------------------------------------------------

这篇文章我只是想表达两个观点：

1、同样是软件开发，但是细分起来，经验不一定通用的。存储过程实现业务逻辑这种方式在传统软件开发领域以及电信、金融普遍使用。

其实，我一直觉得，互联网的web开发与传统软件开发思维方式有些不同！

2、不能被所谓的10年8年开发经验的标签所影响。一个人即便是做了8年10年软件开发，但是放到不同的领域去，有些经验是错误的。

我发现，如果公司是运营网站的，请一个做金融，银行的什么技术总监来。实际上web开发与传统软件开发思维模式不同。web开发需求也是频繁跟着用户去变的。需要的技能是不同。但外行的老板们会以为：做技术10多年了。应该不错哦。请来…

其实，我一直在我有把握确定web开发应该如何做时，就非常抵触。像那个游戏公司就完全搞混了。所谓术业有专攻,即便我不一定经历很多高并发环境，但是由于一个人在这个领域，他会经常去关注这个领域的成熟经验和做法，那么就会知道什么是坑。

同样是技术。呆的领域不同。经验就不同。把那个存储过程放到互联网就出现很多麻烦，扩展性。工作量。

举个亲身例子：我以前呆的公司技术经理是79年的。他可能以前是做java企业级软件开发的,不是做web开发。所以应该没接触过互联网的产品模式(网站大流量要求性能和速度,服务器要抗住)，有次，我发现老板看竞争对手的网站速度访问快了那么点点,怎么会快些，估计不能落后吧（毕竟网站访问速度对用户还是挺重要的），于是想让技术经理优化，哪天我们晚上技术部都加班，结果都没折腾个方案来，经理老是在折腾网站http发送的头部之类的，参考对手网站：咦，他们请求的时候发了一个头，我网站也试一试,看能不能有提升…。其实当时我也没啥经验,才毕业2年不到嘛。但对技术经理的要求当然不同，以现在的角度来看法,只要是长期做web开发，对于网站速度这种问题其实会形成一个套路，绝对不是靠猜测，试来试去的。找瓶颈在哪里。是数据库还是代码。都可以用软件来统计数据的，统计出瓶颈在哪里。靠猜测就会做无用功。使用主要矛盾法(技术术语就是找瓶颈，不是抱着多多益善的方式去试)，把主要矛盾解决了。其他不是影响很大。后面再去做。

以前我总结那么点点经验,不一定正确,只是一点看法，后面没去更新过：http://www.cnblogs.com/wangtao_20/archive/2012/05/10/2493899.html，http://www.cnblogs.com/wangtao_20/p/3304665.html。

当时的技术经理尽管做了8-10年软件开发，但是接触的不是web开发，所以网站速度优化的时候也是走了不少弯路。至少我觉得如果他是从事web开发的话，遇到这种网站速度和性能优化问题，对他这么多年完全是小菜一碟的。其实还好的是，我们当时那种电子商务网站尽管流量和销售额都很多,但是其实并发并不怎么大.弄个mysql主从架构其实就把负载问题给解决了

ps:前面网友提到那个技术经理以参与过广东省移动省级项目来说服，表面看很有说服力：省级的移动项目啊…。但我有自己的思考和判断力，不在同一个领域，思维是不同的。

后来我大量看了一些资料，大家对于使用存储过程封装业务逻辑的好处，归纳起来有以下几点：

• 执行速度快。因为存储过程不需要解析。预先编译了
• 安全性。避免了sql注入，避免了暴露表结构和字段

存储过程可以避免SQL注入是什么道理？

我之前以为是可以避免url中sql注入。后来才明白其实就是针对程序员或者技术而言的：技术完全不知道表结构是什么。获取数据只需要调用存储过程即可。原来是针对开发人员而言的，屏蔽他们对数据库的权限(这么看来，我觉得这些在电信，银行做开发的程序员，其实技能很难提升的，就是调用写好的存储过程，不需要指导表结构，你也不用参与表结构涉及与优化，数据库优化都不用管)，题外话。这样子情况下，放到互联网去做开发反而经验无法套用了。

在url中注入方面。使用存储过程与不使用存储过程都是需要防范的。

存储过程类似于函数，函数的参数预定了参数类型是int还是char等。传入的参数不是int型，会自动转换成int型，从这个角度就是避免了sql注入(我觉得更多是怕开发人员搞鬼 呵呵)。

看到网上有人说：用参数，只能说MS给我们做了一些过滤，SqlParameter规定了你传参数的大小类型
严格过滤还得你自己来 。

我在想，至于严格的判断还是得自己在编写存储过程的时候做严格的过滤。这就像在编写java、php代码进行组装sql的时候做严格的过滤是一样的。从这点来只不过一个是在存储过程编程实现，一个在php、java端实现。

有网友提到：在存储过程里用set来拼接sql语句和直接在代码中拼接没有一点区别…而select * from table where name=@p1这种形式才是安全的…

如果你的存储过程里面没有用参数来拼接sql的话就不会被注入，如果还是拼接，哪和程序代码拼接是一个道理

我也这么觉得，所以我看最大好处还是屏蔽掉程序员(屏蔽掉不懂技术的用户那使用php实现也是一样的)，程序员直接调用存储过程。根本不知道表结构是什么，有什么字段，没有直接暴露表名以及字段名给程序员。银行这类系统安全性第一。程序员人员离职了，也不会影响,只知道存储过程，谈不上攻击。只有几个核心的人知道表结构。

但是，在互联网产品开发中(通俗理解为网站也可以)，不赞成使用存储过程(淘宝阿里巴巴的架dba不赞成使用存储过程)封装业务逻辑的人理由归纳为如下几点：

1、 业务逻辑封装在存储过程中。对数据库的依赖性比较大。一旦要迁移数据库,比如从oracle迁移到mysql等，以前的业务逻辑都得重写(因为存储过程是具体的数据库系统产物,不同的数据库语法不同)。编写的程序尽量要少依赖于具体的数据库

跟台湾一个工程师聊天，收获如下：

其一、他的原则是编写的程序不要太依赖于数据库。他说像存儲過程,觸發器,關聯,視圖表等他幾乎不用

其二、提到有些应用使用存储过程，依赖于数据去实现。他分析原因比较中肯：
他們是很特殊的情況
他們追求的是高效率
而且有錢
他們的機房動輒幾百萬的投資,不是一般小企業能承受的
小企業今天程序可能放在公司,明天可能要搬移到機房
太過於依賴外在因素會死人的

其實大企業我完全不反對他們依賴數據庫,我表弟的工作就是天天寫oracle的輔助程序
完全是依賴數據庫
沒辦法,他在台灣電力

归纳为：电信，金融这些企业占据了很大的资源优势，有钱，关系可以提供好的机房(带宽和网络稳定优势)。oracle数据库上千万的费用都能承受。
硬件可能是定制的，比如花钱购买sun之类的公司的一套设备：操作系统到数据库，完全依赖于某个操作系统和数据库来实现。

2、其实在互联网高并发，大流量的情况下，成熟的做法都是，计算层交给web层，数据库只是存储数据。尽量少让数据库去做运算(也就是ifelse之类的逻辑判断)，不要让脚去做脑瓜子要做的的事情。从这个角度，就是要把计算数据，判断之类的都交给应用代码去解决。不要加重数据库的负担(我觉得，银行业可能不这样子做，他们购买昂贵oracle数据库和ibm之类的服务器一台可能几百万来提高性能)

比如维基百科从mysql迁移到mariadb数据库。很多互联网企业随着数据量大，出于节省成本考虑，迁移数据库很平常的事情。

http://database.51cto.com/art/201304/391559.htm

2、 方便扩展。遇到数据库性能瓶颈。单台数据库服务器永远会存在瓶颈的(极限)，是扛不住的。集中式最终会被分布式给替代，一般在互联网环境下偏向于使用分布式部署数据库。分布式通俗理解，要分库，拆分表。拆分到多台服务器上去。分散压力。如果业务逻辑封装在存储过程中。则不好这样子做。因为存储过程是依赖于某个具体的库的。把计算层放到web层，那么web端的程序只是从多个数据库服务器聚合数据即可了。

google、阿里巴巴其实会通过很多mysql集群来提高性能。

3、 互联网应用频繁修改功能，需求变化快。要响应用户需求为准，这关系到企业的生存。国企往往是资源丰富，大手笔很正常，功能频繁修改来响应市场用户？如果封装在存储过程中，修改功能。维护确实麻烦。其实我觉得，还要考虑招聘成本。很难有既熟悉java又熟悉存储过程编程的人(一门语言懂一点点是可以做到)。银行业，金融业不会频繁的修改功能。我觉得，工商银行会为你了一个顾客说要什么就加一个功能吗？不会。我们去看看工商银行的网站就知道用户体验怎样，也同时看看电信的。在国企的思维模式不同的。敏捷开发在互联网是经常用到的。

如果再让我跟国企、电信、移动、银行业的技术人员沟通，我仍然坚持，尽量少使用存储过程封装业务逻辑。

正如前面网友说的，为了解决性能问题有很多种方案，这种方式可能会差一些，不利于数据库扩展，数据切分。

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

其实，银行业为什么要使用存储过程封装业务逻辑。后面会分析出深层次原因：绝对安全考虑！基于不差钱(依赖于具体的oracle数据库又如何?)的大前提来做的。

实际上，我也觉得，使用存储过程确实减少了二次解析，提高了效率，但是这种效率提到完全可以用其他方式替代。损失的是扩展性。

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

有人想到了：淘宝在mysql中不照样在用？据我从知乎上了解到，阿里从oracle迁移到mysql还是要保留了一定数量的存储过程，是因为历史原因的残留(可能是oracle有很多存储过程残留，没法一下子改掉，系统提供服务运行稳定为主)。搞清楚原因了后更加有利于选择。

不是单纯的站在使用存储过程"不需要编译，提高了效率"这个点，提高了速度的角度去考虑问题。要从整体上：开发成本，以后的维护成本，系统的扩展性，扩容等等。进行权衡取舍。
用这种方式提高了速度，但是系统的扩展性，维护性，开发成本？

很多人让其给建议，也不会直接说一定不用。也只是委婉的(mysql dba)：

可以用,如果你很明确自己的容量和性能,很熟悉存储过程的开发.说点其他的:

1. 随着海量的数据增长,高并发的系统,数据库慢慢转化为仅仅作为数据的容器. 如果你的数据库存在瓶颈,存储器,触发器这些都没用了.
2. 从web层扩展是很容易的.所以把计算留给web层吧.

====================================另外一位

不能一概而论，对于和属于相关性大的业务逻辑和计算，Oracle完全能胜任，逻辑转移到Web层反倒复杂。

=============================================
我想这也是oracle把计算层放在数据库层的原因吧。所以在oracle中可以使用存储过程。

---

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

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

也有人提到：

数据库是相当昂贵的投资，能让他多干点就多干点活。存储过程的优势还是非常强的（在没有跨平台的要求下）。貌似我们公司那帮java的就从来不知道存储过程为何物，用java的框架统一生成，到处是拼接SQL.

数据库是昂贵的投资是oralce的说法，mysql是免费的

---

存储过程作为一种过时的语言，只能存在于较少的业务场景了，比如规范的数据仓库数据清洗、标准、简单的多数据库操作等。

在良好的业务系统中应该尽量抛弃存储过程和触发器之类的东西。
1、从设计角度看，逻辑封装很重要，不是存储过程那一点封装，而是整个业务逻辑。如果把业务逻辑分散在程序代码和存储过程两部分，实际上是业务碎片化，不利于表述业务逻辑，造成后期阅读维护的困难。

2、存储过程自身并不是一种结构化良好的语言，对于习惯于面向对象编程的人而言，简直就是乱麻一堆。代码可读性在工程上很重要。
3、很多真正提高效率的终极办法是使用缓存而不是在数据库中运算，靠数据库预编译或减少网络流量那点优化就可以，那说明性能要求原本不高

4、如果有数据库解耦的需求，就更不应该使用存储过程

好的架构师多是从程序员发展来的，有几个是DBA发展来的？有几个好的架构师常推荐存储过程呢？所以DBA兄弟们最好还是听程序员的话，优化sql即可。
如果真想从架构思路上去优化，先应该全盘考虑系统架构问题。

==================================================================

                   最后归纳

==================================================================

业务逻辑封装在存储过程中，是要看场景使用

一、如果是金融，银行，电信等国企类。使用存储过程影响不大。这种情况是持续了很多年。

好处：

1、银行类系统对于安全性要求很高，存储过程把sql封装起来，完全可以屏蔽sql注入(也不是没替代方案，互联网也有安全性要求比较高的，比如在线支付都可以有其他方式来解决)

2、对系统的速度要求很高。往往是通过花大价钱购买硬件和oracle之类的数据库服务来解决问题，这些企业非常有钱，可以通过花钱购买oracle数据库，良好的硬件来解决。比如一台机子上几百万都可以承受。只要能保证我安全,花钱可以接受。反而在互联网环境下，为了节省成本，互联网大部分公司面对性能瓶颈， 更多使用大量廉价的pc server(一万左右一台)来做集群，从集中式向分布式进行部署。google以前也是使用大量廉价的mysql集群(使用存储过程是没法做到分布式查询,存储过程本来就是在一个库下面)，依赖于某个单个库）。

另外，解决性能瓶颈，互联网大部分还是通过使用缓存来解决的，这跟银行类系统"花费大价钱提高硬件和数据库软件的承载能力"思路是不同的。

从这个角度来说，我其实不觉得电信行业这些人技术多么牛逼。原因在于，他们提高性能的方式其实更多是通过花费大量的钱来购买oracle商业的数据库以及ibm之类的小型中型服务器抗住。通俗说，就是商业公司帮助解决的。

关于oracle数据库：

Oracle主要是依赖中高档存储设备和小型机；而中高档存储设备和小型机的购买费用非常贵，更关键是这些设备的保养费服务费用更加贵，甚至超过设备购买费用；

Oracle不适合大数据量采用PC Server+伪分布式的模式

Version:0.9 StartHTML:-1 EndHTML:-1 StartFragment:00000099 EndFragment:00000813

Oracle 11G的User License无限使用期的价格为人民币3千5左右，按50个User License无限使用期的购买量则价格为17.5万(50* 3500)

每个CPU License无限使用期的价格为17万9千。

每年是20%的服务费(第一年免费)。

我查资料得知小型机(其实我也被这个小字给误解了)：

使用IBM Power系列处理器的System p服务器统称为“小型机”，是区别于X86构架的System X系列服务器的一种称呼。不要以为这个系列的服务器名称中带一个“小”字就小看了他的性能，要知道基于X86构架的计算机设备是被成为“微型机”的。Power处理器区别于Intel至强、AMD皓龙的根本性指标是前者运行精简指令集，而后两者运行复杂指令集，相比之下Power效率更高，并发处理能力更强。采用IBM Power处理器的服务器运行基于UNIX开发的操作系统AIX，一般应用于网络基础构架的后端数据库访问控制或者高性能科学计算领域。

说白了 比一般服务器更要好所有的东西都是IBM 几十年来自己开发的 里面的CPU 就要比因特尔的要强很多 当然也非常的贵 基本上最好都是几十万的 几百万的也有

型号么 一般你看见IBM P550 P570 等等就是小型机了

因为IBM小型机是运行Unix系统（Aix），所以在这个平台上面运行的软件

一般都是基于Java的开发系统，比如应用与银行中介于大型机和普通服务器之间的链接，电信中的中端架构，还有企业，政府中的要求高端运行，高稳定，超低宕机要求的系统。

反推一下，所有不能应用windows,linux 系统的地方基本上都是小型机的天下，而这些里面大部分应用的是IBM 的Aix系统小型机

小型机我看到报价是25万，90万的。

我可以归纳为：花费了大手笔购买的服务器，超强。据说是全年不宕机，非常稳定。性能很牛逼。

那么总结就有钱，不在乎这点钱。

多花钱，能解决我问题就好(保障稳定服务以及安全也很值得)。

使用存储过程封装了业务逻辑，依赖死具体的oracle数据库没关系(oracle在pc server上是跑不了的，必须在昂贵的小型机机上才能发挥优势)，电信企业几十年使用oracle，依赖死都没关系。

我强烈感慨，电信行业这些的技术经验放到互联网大部分民企是行不通的。google那么有钱，仍然要使用大量廉价的pc server。阿里巴巴那么有钱，尚且要把大量数据迁移到mysql做集群，我觉得原因在于：民营企业是要以生存为准的。成本考虑第一。

3、银行类的系统需求不会频繁的变更。功能不能频繁修改，加功能，我觉得银行之类系统不是以用户需要什么功能为标准的，你看看工商银行的网站，功能很好吗?。他们是老大。相对互联网环境下，web开发得不停响应用户体验需求，加新功能是不同的。互联网面对所有用户都能开放访问的环境下，需要开发功能快速响应。所以经常看到在互联网使用的是敏捷开发。频繁的系统功能修改与响应，这种环境下，业务逻辑改动比较多(生存压力，用户需要什么你就给什么)，那么，如果使用存储过程的话，改代码，调试代码都会比较麻烦。

其实，我去看mysql5.1手册中提到存储过程，介绍如下：

MySQL 5.1版支持存储程序和函数。一个存储程序是可以被存储在服务器中的一套SQL语句。一旦它被存储了，客户端不需要再重新发布单独的语句，而是可以引用存储程序来替代。

下面一些情况下存储程序尤其有用：

· 当用不同语言编写多客户应用程序，或多客户应用程序在不同平台上运行且需要执行相同的数据库操作之时。

· 安全极为重要之时。比如，银行对所有普通操作使用存储程序。这提供一个坚固而安全的环境，程序可以确保每一个操作都被妥善记入日志。在这样一个设置中，应用程序和用户不可能直接访问数据库表，但是仅可以执行指定的存储程序。

存储程序可以提供改良后的性能，因为只有较少的信息需要在服务器和客户算之间传送。代价是增加数据库服务器系统的负荷，因为更多的工作在服务器这边完成，更少的在客户端（应用程序）那边完成上。如果许多客户端机器（比如网页服务器）只由一个或少数几个数据库服务器提供服务，可以考虑一下存储程序。

存储程序也允许你在数据库服务器上有函数库。这是一个被现代应用程序语言共享的特征，它允许这样的内部设计，比如通过使用类。使用这些客户端应用程序语言特征对甚至于数据库使用范围以外的编程人员都有好处。

我非常赞同这句话，安全非常重要的时候。银行，金融业安全第一。其他方面一概都不考虑(硬件花钱购买，软件依赖于oracle之类昂贵的数据库系统无所谓)

互联网环境下，存储过程用得还是比较少的。安全性可以有替代方案的。

二、web环境尽量少用。用了弊大于利。使用存储过程，业务逻辑封装在存储过程中，修改功能，维护起来都比较费力。互联网应用恰恰需要快速响应用户需求的变化，应用变化很频繁,业务逻辑修改如果去修改封装业务逻辑的存储过程就会变得很麻烦,就像在互联网产品开发中，由于应用频繁变化,表结构经常需要修改是很多dba头痛的事情(不能影响用户操使用网站)。随着网站用户的增加，网站扛不住了，更多是考虑水平扩展，做集群。你或许可以通过花费大价钱购买设备和数据库服务 ，但是，单个硬件服务器、单个数据库软件承载是有极限的。作为民营企业，你会考虑购买的成本是否扛得住,之前阿里巴巴一年的oracle投入需要4千万左右，后来为了减低成本使用mysql做集群,具体参考：

http://www.linuxeden.com/html/news/20120413/122892.html

能减低成本为什么不减低呢？

互联网是分布式部署居多。通过廉价的pc server集群来达到效果

淘宝有一个动作是去IOE（IBM的小型机、Oracle数据库、EMC高端存储）。早期的淘宝，主要靠的是高端硬件，思路就是用钱解决问题。但是这样做的成本很高，淘宝的业务规模又扩张得太快，所以要用更经济的方案。用PC Server、MySQL数据库等，通过大量廉价的硬件，水平伸缩组成集群，来替代昂贵的硬件，思路就是用技术解决问题。跟google的思路一致。

我一直觉得，技术主管对技术的嗅觉和预见性还是有一些影响的，如果招聘一个银行电信业的技术人员转移到互联网做web开发，其使用存储过程封装业务逻辑在以前看来是很成熟的经验，但是放到互联网web中去，可能是一种早就埋下来的坑。

以前听一个网友提过，电子商务网站，对技术水平的要求倒并不是很高(淘宝阿里巴巴等除外)，大部分只要扛得住即可。我比较认同这个观点。基本的需求满足即可了。

我从来不觉得凡客在使用存储过程可以作为一个良好的佐证：人家不照样在使用么？有什么不能用，我们更多应该参考亚马逊，ebay，阿里巴巴等企业的技术方案，向他们看齐。

题外话，其实互联网的数据大部分不像金融行业要求那么严谨，丢失点点用户数据不至于如何。对数据的一致性要求并不是100%的苛刻。反而银行出于绝对安全考虑，必须要封装在存储过程中实现业务逻辑。其实现在也逐渐看到，金融行业在一些非关键性的业务数据使用mysql，比如日志统计，行为分析等。

用金融、电信、银行业的开发思维方式来考虑互联网，经验不适应，成本提高了很多不说，对于未来的升级和扩展还确实是一个坑(当然不差钱就好办,有时候钱多人傻也没有)。

知乎上面讨论的京东使用的成本：http://www.zhihu.com/question/19818863，也挺有趣的。对于一个利润不是很大的零售业来说，要付出很大一笔钱给微软,微软还是比较封闭的。以下这个网友的观点非常好：

用.Net，意外着你被捆绑在Windows平台上。不是.Net效率本身比Java,PHP差，语言其实差别很小，差距在于：

1. Windows Server授权费太贵，Linux免费，如果你有上千台服务器需要买上千台Windows授权(这跟使用oracle的思路是一样的)…

2. Windows不但贵，性能还远远不如Linux，注意这里说的是服务器端性能，跟桌面一点关系都没有

3. 许许多多无数的开源、高端服务器组件只有Linux/Unix版本，移植到Windows上的基本是半残品

4. 许许多多优化技术、高性能分布式缓存、数据库、NoSQL解决方案等等，仅针对Linux

5. 你需要的一切组件和技术几乎都可以在Linux平台上找到免费、稳定而且高性能的东东，如果是Windows平台，你需要祈祷微软赶快开发出来

6. 在虚拟化的今天，一台高性能服务器可以跑十几台虚拟机，用Linux，你得到的是免费、稳定的虚拟机，用Windows，你一台服务器的授权费将 x N。

总之，立志做大型互联网应用的企业，绝对绝对绝对不可以用Windows Server做平台。

京东一开始估计招了会.Net的人，开发效率高不意味运营效率高，一开始大方向错了，越往后越难改。

＝＝ 补充一点 ＝＝

不 是不看好.Net语言本身，而是这是Windows Server和Linux平台的对决，要先选对平台，再考虑具体用什么语言开发。平台选错了，无论你怎么努力，都不可能最终成功，因为Windows不是 你控制的，你也无法修改Windows，而全世界最优秀的开发人员每天都在为Linux添砖加瓦。

做互联网要抛弃大企业那种IT外包／“给微软OracleIBM付费即可做好IT服务”的思想，一切均要靠自己！

================================================

非常认同这句：做互联网要摈弃大企业那种it外包的思想，一切均要靠自己！

互联网应用。如果网站用户数很大扛不住了，如果遇到瓶颈了，这种可能是厂商都没遇到过的(比阿里巴巴之类的应用就是)，因为厂商尽管说是支持多大性能，但是缺乏互联网大规模实际检验的测验。当oracle、微软没法给你解决问题这些问题的时候。这个时候就必须得创造技术，或者修改源代码来符合自己业务需要(一个封闭系统源代码封闭起来你控制，必须祈祷于微软等厂商来给你解决)。传统软件开发领域电信、银行业的人哪怕有10年20年的经验，他的经验放到互联网有时候是错误的。这个存储过程封装业务逻辑也是一样的。在电信大企业都是这样子用。到了互联网，这样子用，我觉得就是坑。

语言的选择本质就是平台的选择：http://dbanotes.net/review/choose_programming_languages_important.html

=========================
来个总结

==========

业务逻辑，封装在存储过程，导致的问题：

1、会依赖死数据库。切换数据库比较麻烦，比如从sqlserver切换到mysql。因为存储过程是依赖于具体的数据库的。
2、存储过程的语法，不太符合程序员的思维习惯，维护这样一堆东西，维护困难。招聘开发人员容易，招聘懂存储过程的少
3、数据库的任务应该是专注于存储数据，至于业务逻辑的实现，交给程序来实现灵活扩展。数据库负责提供数据，至于拿到数据后，怎么处理，交给应用程序来，想怎么弄就怎么弄

存储过程封装业务逻辑的做法，一般在这样的行业：金融，银行、国企。

原因是：这样的行业，有钱，依赖死某个具体的数据库厂商(比如微软的sqlserver)没有多大关系的，那点钱小问题，换什么数据库呢。另外，这样的系统，业务变化少，需求固定，比如银行的计费，这些不会像互联网网站，产品会提各种改动需求。于是这类系统，不会频繁地修改业务逻辑。所以不太那么需要经常去修改存储过程的逻辑。

如果像互联网网站，需要频繁修改业务逻辑(以适应市场变化，否则被用户淘汰)，那么去修改存储过程，调试是比较麻烦的(至少没有像开发程序那样容易)。

本篇文章有感而发，我一直觉得，专攻方向不同，经验则是不同的。不是说做了10年8年，然后放到互联网就通用。我非常肯定一点，在互联网环境下更多就是靠web层来计算，靠缓存和分布式来应对大流量访问，而不是像银行业那样子大手笔花钱购买商业数据库系统(如oracle)和几十万到几百万一台的小型机来提高性能。他们绑定死依赖死某个具体的数据库没关系，他们要的数据安全，出了问题可以找厂商负责。何况他们也也不差钱吧。当你在电信做了10年开发，把这种存储过程实现业务逻辑的经验放到互联网，不一定是什么滔天大罪的事情，但我觉得就是一个坑，未来埋下的坑。

我觉得，具备自己的独立思考能力非常重要。不能被别人的10年20年开发经验影响而所放弃独立的思考，就像受到工商银行的技术总监头衔所影响的那样子。金融、电信、银行业那套经验不用移植过来。