為什么阿里巴巴禁止使用存儲過程？

作者：楊洋的圍脖啊
來源：segmentfault.com/a/1190000011138993

我覺得存儲過程挺好用的，為什么你不建議用？

翻看了代碼發(fā)現(xiàn)，系統(tǒng)的用戶個人頁面的C#代碼調(diào)用了三個存儲過程，去抓取用戶的Job,Certification,Disclosure數(shù)據(jù)。
我的新需求，自然需要復(fù)用這三個存儲過程，否則:

若每一處都寫一次抓取數(shù)據(jù)的業(yè)務(wù)邏輯代碼，若業(yè)務(wù)邏輯發(fā)生變化，難以追查和維護所有讀取Job,Certification,Disclosure的SQL。

如果我在C#代碼中調(diào)用這已有的三個存儲過程，事情本該非?？炀湍芙Y(jié)束。我也是這么做的。搜索公眾號互聯(lián)網(wǎng)架構(gòu)師后臺回復(fù)“2T”，獲取一份驚喜禮包。

但code reviewer認(rèn)為，我的需求中，并不需要Job,Certification,Disclosure這三個業(yè)務(wù)對象的數(shù)據(jù)。我只是需要給定用戶_是否_有Job,Certification,Disclosure而已。所以我應(yīng)將是否有無Job,Certification,Disclosure的判斷邏輯寫在數(shù)據(jù)庫，最終通過網(wǎng)絡(luò)從數(shù)據(jù)庫傳到web服務(wù)器的僅是true或false，節(jié)省網(wǎng)絡(luò)流量，這樣最好不過了。

也對。除開網(wǎng)絡(luò)性能，從接口設(shè)計的角度講，接口的傳入和返回值，都應(yīng)是你本身需要的數(shù)據(jù)，不應(yīng)帶有大量不需要或者需要caller去預(yù)處理的數(shù)據(jù)。從接口語義表達(dá)就可知調(diào)用的目的，這樣代碼可讀性也會有大大提高。

那就動手改。但沒想到的是問題來了。

為了講述問題，我簡化代碼，假設(shè)系統(tǒng)現(xiàn)有的存儲過程如下：

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本身并不支持這種用法。

搜索公眾號互聯(lián)網(wǎng)架構(gòu)師后臺回復(fù)“2T”，獲取一份驚喜禮包。

給現(xiàn)有存儲過程GetJobs加output參數(shù)？本例中因為GetJobs已被其他多處代碼或SQL scripts調(diào)用，所以對現(xiàn)有現(xiàn)有存儲過程進(jìn)行改動會有不小風(fēng)險。

我搜遍網(wǎng)絡(luò)，一位MS MVP的大神的文章幾乎總結(jié)了所有存儲過程之間傳遞數(shù)據(jù)的方法: 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的語句寫一了次。

存儲過程在很多場景時有其優(yōu)勢，比如性能。但對于業(yè)務(wù)邏輯的通用方法，非常不推薦將其寫在存儲過程中，代碼復(fù)用、擴展與客戶端語言比，相差甚遠(yuǎn)。也許終究能實現(xiàn)，但代價與風(fēng)險比客戶端語言要高，得不償失。

天知道還有沒有機會和那位前同事再討論這一話題呢。