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

作者：杨洋的围脖啊
来源：segmentfault.com/a/1190000011138993

我觉得存储过程挺好用的，为什么你不建议用？

翻看了代码发现，系统的用户个人页面的C#代码调用了三个存储过程，去抓取用户的Job,Certification,Disclosure数据。
我的新需求，自然需要复用这三个存储过程，否则:

若每一处都写一次抓取数据的业务逻辑代码，若业务逻辑发生变化，难以追查和维护所有读取Job,Certification,Disclosure的SQL。

如果我在C#代码中调用这已有的三个存储过程，事情本该非常快就能结束。我也是这么做的。搜索公众号互联网架构师后台回复“2T”，获取一份惊喜礼包。

但code reviewer认为，我的需求中，并不需要Job,Certification,Disclosure这三个业务对象的数据。我只是需要给定用户_是否_有Job,Certification,Disclosure而已。所以我应将是否有无Job,Certification,Disclosure的判断逻辑写在数据库，最终通过网络从数据库传到web服务器的仅是true或false，节省网络流量，这样最好不过了。

也对。除开网络性能，从接口设计的角度讲，接口的传入和返回值，都应是你本身需要的数据，不应带有大量不需要或者需要caller去预处理的数据。从接口语义表达就可知调用的目的，这样代码可读性也会有大大提高。

那就动手改。但没想到的是问题来了。

为了讲述问题，我简化代码，假设系统现有的存储过程如下：

CREATE PROCEDURE [dbo].[GetJobs]
(
    @PersonId int,
    @OrganizaitionId int
 )
AS
BEGIN
  SELECT JobId,JobName,JobType FROM Job WHERE PersonId = @PersonId AND OrganizaitionId = @OrganizaitionId
END

CREATE PROCEDURE [dbo].[MyProc]
(
    @PersonId int,
    @OrganizaitionId int,
 )
AS
BEGIN
  CREATE TABLE #Temp(
    PersonId int,
    OrganizaitionId int
  )

  INSERT INTO #Temp EXEC dbo.GetJobs
    @PersonId = @PersonId,
    @ParentOrgId = @ParentOrgId

  SELECT COUNT(*) FROM #Temp
END

那么将MyProc中的INSERT INTO换为SELECT INTO呢？很遗憾，答案是不行。SQL本身并不支持这种用法。

搜索公众号互联网架构师后台回复“2T”，获取一份惊喜礼包。

给现有存储过程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的语句写一了次。

存储过程在很多场景时有其优势，比如性能。但对于业务逻辑的通用方法，非常不推荐将其写在存储过程中，代码复用、扩展与客户端语言比，相差甚远。也许终究能实现，但代价与风险比客户端语言要高，得不偿失。

天知道还有没有机会和那位前同事再讨论这一话题呢。