我用的是postgresql,發現同樣的邏輯，儲存過程的程式碼是c#的三分之一。因為儲存過程語言是為描述資料建立的，對於變數和資料的混合處理有天然優勢。再加上一些註釋，程式碼可讀性比c#更高。而且由於伺服器和資料庫是一次互動，執行更快，使用者體驗好，伺服器併發好。postgresql儲存過程支援斷點除錯的。當然我不建議幾千行的儲存過程。儲存過程的目的是為了執行速度更快，程式碼更簡潔。我也不認為簡單的增刪改查也用儲存過程。這些應該交給orm。儲存過程應該用同時滿足以下幾個條件時：1.使用者高頻使用這個功能 2.這個功能需要多次訪問資料庫

儲存過程的另一個好處是在編譯時就可以檢查sql語句的錯誤不用等執行。缺點是，當資料庫修改後，你如果不重新編譯儲存過程是無法知道程式中哪些地方需要修改欄位名。但是相比她帶來的好處，這一點可以忍受。另外orm也只是可以檢測欄位，但是儲存過程連語法都檢測了。

現代網際網路應用的基石是MySQL,而早期mysql沒有儲存過程，而且資料往往要分多個庫，搞儲存過程要一個個庫去更新，萬一漏了一個就會出問題。網際網路應用的邏輯相對沒有erp複雜，所以都不用儲存過程。但是現在是2019年了，mysql資料庫也支援分割槽表了，一個庫就能搞定很大資料量。儲存過程也支援了，適當使用儲存過程並無不妥。尤其是postgresql資料庫連斷點除錯都具備了，語法又那麼優雅。

所以我支援用儲存過程，但不能濫用，要好鋼用刀刃上

一、在SQL Server中儲存過程不會影響效能。1、只會大大的減輕伺服器的壓力，而不會增加，只有不合理的儲存過程才會造成伺服器效能下降的惡果。一個大型的資料庫，一般儲存過程也不會超過幾千個，對當前的資料庫及它依附的硬體來說，這點兒負載是大象身上的老鼠，負載基本可以怱略不計。2、但是，儲存過程是批次的SQL語句的合成，如果設計上混亂，引發死迴圈、死鎖、大範圍查詢、臨時表沒有及時清理釋放等問題的情況下，是會嚴重影響伺服器效能的，但這根子不在儲存過程上，而在於儲存過程的設計上。錯誤的SQL程式碼指揮伺服器，無論它的形式是儲存過程，還是客戶端及時發向資料庫的請求，都會使伺服器出現問題。二、相關擴充套件1、在當前，針對資料庫的程式設計設計，沒有儲存過程是不可想象的，這就象某個公司的大型貨品倉庫中沒有倉庫保管員一樣，所有的貨品進出都得進貨員或銷售員去臨時取放，會嚴重降低工作效率。2、儲存過程在資料庫中無論是否編譯好，其效率都要比客戶端臨時向資料庫傳送指令調資料來得要高，因為至少減少了發向伺服器的指令的量。況且很多的中間值、臨時值如果不透過儲存過程來實現的話，就只能先全取到客戶端，這樣會大大增加網路負擔與伺服器的負鉭。3、正如微軟所說，儲存過程來實現，可以使得很多中間量不必傳入到客戶上，客戶端只能得到需要的結果，所以同時可以提高安全。