存储过程口水战

不知道什么时候起阿里巴巴Java开发手册里要求禁止使用存储过程。一时间，几乎所有公司的开发手册上都明令禁止使用存储过程。

---

如果你的公司名字叫阿里巴巴，请快速点击窗口最右上角的X。

如果你的公司名字叫京东，请快速点击窗口最右上角的X。

---

作为一个从Foxbase-->FoxPro->Access->Paradox->SqlServer->Oracle->MySql->PolarDB都常年倒腾千万级、亿级数据的不正经的老程序员，用不严谨的文字战战兢兢地盘点一下。

已戴头盔，欢迎拍砖。。。

 

一、可移植

【我不用】：存储过程可移植性低。

【我用】：移植？如果做一个产品，这是对的。如果做一个项目，特别是生产项目，只有花别人的钱办别人的事才会这么想。

凡生产系统涉及数据库移植，肯定是系统彻底重构了，还能不重构数据库？

移植性在我看来是个伪命题，绝大多数的产品，终其生命周期数据量都很难超出关系型数据库的支持范畴。如果存在这种可能，那么选型的时候就该考虑好。

小型系统管理、毕业设计之类的系统，可以改个连接字符串就切换数据库服务，你随便找个ERP试试？

二、分库分表

【我不用】：储过程不利于将来分库分表

【我用】：98%的程序员都没沾过分库分表的项目。1%的人做完分库分表的项目没法维护跑路了，1%的人在BAT。

三、维护调试

【我不用】：存储难维护、难调试。

【我用】：如果能弄清楚为什么要使用存储过程的程序员，这些都不是事。存储过程一样可以写的很优雅，水平问题而已。再说了，弄不懂存储过程的DBA，你敢要吗？

四、开发难度

【我不用】：并不是所有开发人员都熟悉怎么使用存储过程，包括像怎么用SQL表示各种复杂逻辑，怎么调试存储过程。

【我用】：写SQL的人弄不懂存储过程就如同用Java的人不懂反射和泛型。不掌握数据库特性，很难写出让人放心的SQL。开发人员的头可能不会秃，但老板、项目经理、测试经理、DBA的头全秃了。

五、业务逻辑集中

【我不用】：从软件设计的角度来说，业务逻辑的实现要集中在一起，这才是好管理的，好维护的，出了问题你才能容易找得到。这样的软件系统也是好设计的，好测试的。

【我用】：这一点有道理，毕竟写Java或C#要比写存储过程容易。但不能脱离场景，我现在做的是一个Api平台，输出100个以内的Api，业务明确、规模可控。一个Api对应一个存储过程，存储过程有严格的版本控制。开发、维护成本是纯后端代码的1/5不到。性能高，可快速无感更新或回撤。每天两百万次复杂查询（响应时间68毫秒）、10万笔交易，10年来一人轻松维护无逻辑故障。

六、项目管理

【我不用】：从项目管理的角度来讲，找java程序员比找dba容易。

【我用】：不能一刀切，并非所有存储过程都很复杂，并非所有逻辑都使用存储过程。另外，有没有想过Java程序员和DBA的比例？

七、scale

【我不用】：从scale的角度来说，是应用层好scale还是关系型数据库好scale上去？当然都能scale, 不过应用层要容易好多，一般来说你多加服务器就好了。

【我用】：用了存储过程的系统应用层也是可以scale的。再说，大部份程序员职业生涯中写的应用都跑不满一台服务器，没必要什么项目都按淘宝的标准设计。当然，花别人的钱办别人的事除外，项目做不好没关系，再写份好简历就行。对了，阿里云的PolarDB请了解一下。

八、系统瓶颈

【我不用】：从系统瓶颈的角度来讲，十个系统有九个瓶颈在数据库，用存储过程大大增加数据库压力。

【我用】：用存储过程并不会增加数据库压力，存储过程是会增加DB服务器的少量CPU开销，但把存储过程的逻辑拆解为独立SQL往往总开销都远大于存储过程总开销，并且是宝贵的磁盘IO开销。

九、总结

离开场景讨论技术都是耍流氓。阿里手册上规定禁止使用存储过程的场景是基于阿里的应用类型、应用规模、团队配置的。

如果你的公司不是阿里 or 开发的不是淘宝 or 没有阿里的团队配置，请慎重考虑。

---

分享一张系统截图：

---

本来还想打个广告。。。还没想好。。。