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

大家好，我是鸭哥。

之所以有这个题目，我既不是故意吸引眼球，也不想在本文对存储过程进行教科书般论述。

最近项目中遇到的存储过程问题，让我想起了去年在武汉出差时一位同事的发问：

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

现在想来，我最近正碰到的问题，算是一个可以回答同事的例子吧。

最近项目中有个新需求，需要校验一个用户是否有Job,Certification,Disclosure这三个业务数据。

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

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

如果我在C#代码中调用这已有的三个存储过程，事情本该非常快就能结束。我也是这么做的。

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

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

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

为了实现这一目的，首先想到的是使用临时表，将返回结果集存入临时表，再对其进行count(*)的计数操作：

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中的临时表结构也需要随之变化。这是令人难以接受的。

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

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

来源：sf.gg//a/1190000011138993

程序员技术交流群

有不少同学给鸭哥说，现在进大厂太难了！赚钱太难！因此，鸭哥特意邀请了华为、腾讯、阿里的朋友进群，与大家一起交流经验，一起增长技术。

有兴趣入群的同学，可长按扫描下方二维码，一定要备注：城市+昵称+技术方向，根据格式备注，可更快被通过且邀请进群。

▲长按扫描

近期技术热文

点击下方公众号

回复关键字【666】

领取资料

我就知道你会点赞+“在看”