为何阿里禁止使用存储过程？

送你们如下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去预处理的数据。从接口语义表达就可知调用的目的，这样代码可读性也会有大大提升。

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

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

`CREATE PROCEDURE [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(*)的计数操做：

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

那么将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的语句写一了次。

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

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