儲存過程與中間層（c#）中的業務邏輯
這更像是一個架構問題。我曾經在一家擁有 Web 應用程序的金融公司工作。
前端 JavaScript。
中間層是訪問後端 SQL Server 的 WebAPI。
後端 SQL Server 數據庫。
該公司將其所有業務邏輯都放在儲存過程中。和其他公司聊過之後，我開始聽說他們大部分的業務邏輯都放在了中間層。
我曾經問過金融公司的某個人，為什麼這麼多地使用儲存過程，但沒有得到很好的答案。最近，在一次工作面試中，他們詢問將所有業務邏輯放在數據庫中與中間層相比有什麼優點和缺點。我沒有一個好的答案。
誰能提供一些關於為什麼這是或不是一個好主意的想法？
A) 規模 中間層可以很容易地擴展——因此有了網路農場的概念。擴展數據庫層要困難得多。雖然有些 產品 可以做到這一點，但它還不是微不足道的主流。
B) 成本通常，Web 伺服器是普通的或花園的盒子。然而，數據庫伺服器往往更大、更複雜且更具彈性。這一切都轉化為“昂貴”。一位最近的雇主估計數據庫上的 CPU 滴答聲比應用伺服器上的 CPU 滴答聲貴十倍。
**C)**包含在儲存過程中的重用邏輯不能簡單地連結到例如獨立的移動應用程序中。更改 SP 會影響使用該數據庫的每個應用程序，無論該應用程序是否已準備好進行更改。
**D)**儲存過程中體現的重用邏輯對於所有使用數據庫的應用程序都是通用的。程序員不能隨心所欲地迴避規則。更改 SP 會影響使用該數據庫的每個應用程序，從而確保整個企業的一致性。
E) 工具與數據庫相比，應用層中可用於開發的語言、工具和技術更多、更複雜（來自評論，感謝）。
F) 網路流量通常一個業務功能需要多次讀取和/或寫入。通常，一個語句的輸出將成為後續語句的輸入。如果 SQL 語句保存在應用程序中，則每個語句都需要到伺服器的網路往返。如果 SQL 保存在儲存過程中，將有一次網路跳閘，發送參數並僅接收最終結果；避免了中間結果的網路成本。
在看到邁克爾格林的回答，其中充滿了偉大的觀點之後，我想提供一些額外的想法來衡量他的觀點。我並不是想為使用儲存過程本身贏得爭論，但我確實相信它們在這類對話中經常被誤解和/或歪曲。
A) 規模- 無論您將 SQL 語句儲存在儲存過程中還是在中間層中，都必須執行它們。所以 CRUD 操作不會更好地擴展，這可能是我們在這裡討論的 99%。但是對於不僅僅是簡單的 CRUD 的真正業務邏輯，是的，除非您有充分的理由這樣做，否則您通常不應該將其放入數據庫中。有時有充分的理由，例如絕對防止不良數據或額外的安全性。
B) 成本- 我不能在理論上與這個爭論，但我可以在實踐中爭論它。不應假定將程式碼從 SQL Server 移至中間層必然等同於從 SQL Server 解除安裝工作。通常，開發人員只會使用他們必須完成的工作來完成工作。如果他們需要為一個頁面獲取 20 條記錄，而他們只能訪問一次只給他們 1 條記錄的方法，他們可能會使用它並讓它呼叫數據庫 20 次，然後他們才會想到說“嘿，我能找到一種新方法來一次性獲取我需要的所有記錄嗎？” 這只是一個非常簡單的例子來說明這一點，但這可以通過多種方式體現出來。不同的團隊為他們的開發人員提供不同級別的堆棧訪問權限，因此我不明白您可能會或可能不會與您團隊的特定範例相關；希望你明白這一點。在儲存過程中使用 SQL 也為讓 DBA 盡其所能幫助您從數據庫中獲得最大性能打開了大門。將其全部放在中間層關閉了這扇門，現在您更多地依賴開發人員（他們很少是 SQL 專家）來調整您的查詢。
C) 重用——我不得不說我不明白“儲存過程中體現的邏輯不能簡單地連結到，比如說，一個獨立的移動應用程序”這句話的意思。如果邏輯在儲存過程中，則無需這樣做；所以這聽起來像是在說“你不能用你不需要用儲存過程做的儲存過程來做這件事”。誠然，我可能（可能）嚴重誤解了這裡的案例場景，所以我歡迎評論來解釋，因為如果我不明白，那麼可能很多其他人也不明白。
D)“更改 SP 會影響使用該數據庫的每個應用程序，無論該應用程序是否已準備好進行更改。” 如果您的中間層是通過服務訪問的，那麼這個問題並沒有真正得到緩解；您剛剛將相同的問題移至中間層。但是，如果您的中間層是分佈式的（即，您將一個 dll 複製到每個使用項目中以使用），那麼您可以推遲更新單個項目……這會打開一個完整的“另一罐蠕蟲”。就像您需要對現在尚未更新的應用程序進行修補程序一樣，您必須獲取舊版本的程式碼來修復並管理單獨的程式碼分支，或者您必須硬著頭皮更新使用最新的中間層程式碼的應用程序。當然，中間層的支持者會在他擁有的地方提供解決方案，等等……，一個方法的多個版本！現在你又回到了原點。我並不是說一種方法比另一種更好或更差。我只是說無論哪種方式都有問題需要解決，您應該考慮哪種方式最適合您的特定環境。
E) 工具- “與數據庫中的相比，應用程序層中可用於開發的語言、工具和技術更多、更複雜（來自評論，感謝）。” 另一方面，有非常複雜的工具和有才華的人可以在訪問儲存過程時調整您的數據庫。他們可以找到瓶頸並修復它們，但這項工作因為當 sql 處於中間層並且 SQL 專家無法修復開發人員編寫的生成蹩腳 SQL 的程式碼時要困難得多。再次，這是一個權衡。在這一點上，我的意見是考慮誰在您的團隊中，並在做出決定時優先考慮他們最滿意的事情，因為它會嚴重影響開發時間，這對您而言可能超過伺服器的成本。