为什么阿里巴巴禁止使用存储过程？

点击上方“码农突围”，马上关注

这里是码农充电第一站，回复“666”，获取一份专属大礼包

真爱，请设置“星标”或点个“在看”

来自：杨洋的围脖啊 | 责编：乐乐

链接：segmentfault.com/a/1190000011138993

   正文   

之所以有这个题目，我既不是故意吸引眼球，也不想在本文对存储过程进行教科书般论述。《阿里巴巴Java开发手册》是这样规定的：
再结合我最近项目中遇到的存储过程问题，所以今天我打算来聊一聊这个问题。这事儿要从去年在武汉出差时一位同事的发问说起，问题是这样的：我觉得存储过程挺好用的，你为什么不建议用呢当时我好似胸有万言，但终究没用一个实在的例子回答同事，只是从结论上大侃一通，代码相对于SQL，复用、扩展、通用性都要更强。想必同事并不信服。现在想来，我最近正碰到的问题，算是一个可以回答同事的例子吧。最近项目中有个新需求，需要校验一个用户是否有Job,Certification,Disclosure这三个业务数据。翻看了代码发现，系统的用户个人页面的C#代码调用了三个存储过程，去抓取用户的Job,Certification,Disclosure数据。我的新需求，自然需要复用这三个存储过程，否则:若每一处都写一次抓取数据的业务逻辑代码，若业务逻辑发生变化，难以追查和维护所有读取Job,Certification,Disclosure的SQL。如果我在C#代码中调用这已有的三个存储过程，事情本该非常快就能结束。我也是这么做的。但code reviewer认为，我的需求中，并不需要Job,Certification,Disclosure这三个业务对象的数据。我只是需要给定用户是否有Job,Certification,Disclosure而已。所以我应将是否有无Job,Certification,Disclosure的判断逻辑写在数据库，最终通过网络从数据库传到web服务器的仅是true或false，节省网络流量，这样最好不过了。也对。除开网络性能，从接口设计的角度讲，接口的传入和返回值，都应是你本身需要的数据，不应带有大量不需要或者需要caller去预处理的数据。从接口语义表达就可知调用的目的，这样代码可读性也会有大大提高。那就动手改。但没想到的是问题来了。为了讲述问题，我简化代码，假设系统现有的存储过程如下：
CREATEPROCEDURE [dbo].[GetJobs]
(
@PersonId int,
@OrganizaitionId int
)
AS
BEGIN
SELECT JobId,JobName,JobType FROM Job WHERE PersonId = @PersonId AND OrganizaitionId = @OrganizaitionId
END
我在新的存储过程中调用它，我需要获得该person的jobs的数量，即GetJobs返回结果集的count。为了实现这一目的，首先想到的是使用临时表，将返回结果集存入临时表，再对其进行count(*)的计数操作：CREATEPROCEDURE [dbo].[MyProc]
(
@PersonId int,
@OrganizaitionId int,
)
AS
BEGIN
CREATETABLE#Temp(
PersonId int,
OrganizaitionId int
)

INSERTINTO#Temp EXEC dbo.GetJobs
@PersonId = @PersonId,
@ParentOrgId = @ParentOrgId

SELECTCOUNT(*) FROM#Temp
END
这种办法简单有效，但它存在严重的维护问题。未来如果被调用的存储过程的返回结果集字段有变动，那么MyProc中的临时表结构也需要随之变化。这是令人难以接受的。那么将MyProc中的INSERT INTO换为SELECT INTO呢？很遗憾，答案是不行。SQL本身并不支持这种用法。给现有存储过程GetJobs加output参数？本例中因为GetJobs已被其他多处代码或SQL scripts调用，所以对现有现有存储过程进行改动会有不小风险。我搜遍网络，一位MS MVP的大神的文章几乎总结了所有存储过程之间传递数据的方法: How to Share Data between Stored Procedures。他在文章中也无可奈何地说道Keep in mind that compared to languages such as C# and Java, Transact-SQL is poorly equipped for code reuse, why solutions in T‑SQL to reuse code are clumsier.最终我没能找到一种满意的办法，无奈之下我在新写的存储过程中将查询Jobs的语句写一了次。存储过程在很多场景时有其优势，比如性能。但对于业务逻辑的通用方法，非常不推荐将其写在存储过程中，代码复用、扩展与客户端语言比，相差甚远。也许终究能实现，但代价与风险比客户端语言要高，得不偿失。天知道还有没有机会和那位前同事再讨论这一话题呢。

---END---

重磅！鱼哥微信好友坑位限时开放啦！
福利来啦！扫码直接加鱼哥微信号，送你一份刷题指南和面试手册，不仅可以围观鱼哥平时所思和复盘的内容。还可以帮你免费内推大厂，技术交流，一起探索职场突围，收入突围，技术突围。一定要备注：开发方向+地点+学校/公司+昵称（如Java开发+上海+拼夕夕+猴子）
▲长按加鱼哥微信，赶紧上车

推荐阅读

•   再见，Navicat！这个IDEA的兄弟，真香！•   阿里程序员常用的 15 款开发者工具！•   Mysql，再见吧！select * !•   40 个 Java 多线程问题总结•   阿里规定超过3张表，禁止JOIN，为何？•   工作8年，年薪资从1w涨到7w，网友：本科的话有点牛逼了推荐一个不错的Github号，带你发现Github有趣的世界，值得关注，不容错过！
如有收获，点个在看，诚挚感谢