之所以有這個(gè)題目，我既不是故意吸引眼球，也不想在本文對(duì)存儲(chǔ)過(guò)程進(jìn)行教科書(shū)般論述。最近項(xiàng)目中遇到的存儲(chǔ)過(guò)程問(wèn)題，讓我想起了去年在武漢出差時(shí)一位同事的發(fā)問(wèn)：

我覺(jué)得存儲(chǔ)過(guò)程挺好用的，為什么你不建議用？

當(dāng)時(shí)我好似胸有萬(wàn)言，但終究沒(méi)用一個(gè)實(shí)在的例子回答同事，只是從結(jié)論上大侃一通，代碼相對(duì)于SQL，復(fù)用、擴(kuò)展、通用性都要更強(qiáng)。想必同事并不信服。

現(xiàn)在想來(lái)，我最近正碰到的問(wèn)題，算是一個(gè)可以回答同事的例子吧。

最近項(xiàng)目中有個(gè)新需求，需要校驗(yàn)一個(gè)用戶是否有Job,Certification,Disclosure這三個(gè)業(yè)務(wù)數(shù)據(jù)。

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

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

如果我在C#代碼中調(diào)用這已有的三個(gè)存儲(chǔ)過(guò)程，事情本該非常快就能結(jié)束。我也是這么做的。

但code reviewer認(rèn)為，我的需求中，并不需要Job,Certification,Disclosure這三個(gè)業(yè)務(wù)對(duì)象的數(shù)據(jù)。我只是需要給定用戶是否有Job,Certification,Disclosure而已。所以我應(yīng)將是否有無(wú)Job,Certification,Disclosure的判斷邏輯寫在數(shù)據(jù)庫(kù)，最終通過(guò)網(wǎng)絡(luò)從數(shù)據(jù)庫(kù)傳到web服務(wù)器的僅是true或false，節(jié)省網(wǎng)絡(luò)流量，這樣最好不過(guò)了。
也對(duì)。除開(kāi)網(wǎng)絡(luò)性能，從接口設(shè)計(jì)的角度講，接口的傳入和返回值，都應(yīng)是你本身需要的數(shù)據(jù)，不應(yīng)帶有大量不需要或者需要caller去預(yù)處理的數(shù)據(jù)。從接口語(yǔ)義表達(dá)就可知調(diào)用的目的，這樣代碼可讀性也會(huì)有大大提高。

那就動(dòng)手改。但沒(méi)想到的是問(wèn)題來(lái)了。

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

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

我在新的存儲(chǔ)過(guò)程中調(diào)用它，我需要獲得該person的jobs的數(shù)量，即GetJobs返回結(jié)果集的count。

為了實(shí)現(xiàn)這一目的，首先想到的是使用臨時(shí)表，將返回結(jié)果集存入臨時(shí)表，再對(duì)其進(jìn)行count(*)的計(jì)數(shù)操作：

CREATE PROCEDURE [dbo].[MyProc] (@PersonId int,@OrganizaitionId int,) AS BEGINCREATE TABLE #Temp(PersonId int,OrganizaitionId int)INSERT INTO #Temp EXEC dbo.GetJobs@PersonId = @PersonId,@ParentOrgId = @ParentOrgIdSELECT COUNT(*) FROM #Temp END

這種辦法簡(jiǎn)單有效，但它存在嚴(yán)重的維護(hù)問(wèn)題。未來(lái)如果被調(diào)用的存儲(chǔ)過(guò)程的返回結(jié)果集字段有變動(dòng)，那么MyProc中的臨時(shí)表結(jié)構(gòu)也需要隨之變化。這是令人難以接受的。

那么將MyProc中的INSERT INTO換為SELECT INTO呢？很遺憾，答案是不行。SQL本身并不支持這種用法。

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

我搜遍網(wǎng)絡(luò)，一位MS MVP的大神的文章幾乎總結(jié)了所有存儲(chǔ)過(guò)程之間傳遞數(shù)據(jù)的方法: How to Share Data between Stored Procedures。他在文章中也無(wú)可奈何地說(shuō)道

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.

最終我沒(méi)能找到一種滿意的辦法，無(wú)奈之下我在新寫的存儲(chǔ)過(guò)程中將查詢Jobs的語(yǔ)句寫一了次。

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

天知道還有沒(méi)有機(jī)會(huì)和那位前同事再討論這一話題呢。

來(lái)源：楊洋的圍脖啊 sf.gg/a/1190000011138993

---

:-D 搜索微信號(hào)（ID：芋道源碼），可以獲得各種 Java 源碼解析、原理講解、面試題、學(xué)習(xí)指南。

:-D 并且，回復(fù)【書(shū)籍】后，可以領(lǐng)取筆者推薦的各種 Java 從入門到架構(gòu)的 100 本書(shū)籍。

:-D 并且，回復(fù)【技術(shù)群】后，可以加入專門討論 Java、后端、架構(gòu)的技術(shù)群。

來(lái)吧，騷年~

• 《Java 2019 超神之路》
• 《Dubbo 實(shí)現(xiàn)原理與源碼解析 —— 精品合集》
• 《Spring 實(shí)現(xiàn)原理與源碼解析 —— 精品合集》
• 《MyBatis 實(shí)現(xiàn)原理與源碼解析 —— 精品合集》
• 《Spring MVC 實(shí)現(xiàn)原理與源碼解析 —— 精品合集》
• 《Spring Boot 實(shí)現(xiàn)原理與源碼解析 —— 精品合集》
• 《數(shù)據(jù)庫(kù)實(shí)體設(shè)計(jì)合集》
• 《Java 面試題 —— 精品合集》
• 《Java 學(xué)習(xí)指南 —— 精品合集》

總結(jié)

以上是生活随笔為你收集整理的bat 存储过程返回值_为什么不推荐使用存储过程？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。