把業務邏輯寫在存儲過程當中有哪些缺點和優勢？

https://segmentfault.com/q/1010000000251484

個人觀點：這麼設計的目的並不能方便隨時修改業務邏輯，只是方便熟悉存儲過程的開發人員，可以隨時修改業務邏輯。對於後續的業務邏輯越趨於複雜，修改就越困難，存儲過程當中的重複代碼就越多；重複代碼越多，系統的壞味道就越散發開來。

因爲.net在一些系統UI展現控件上，跟數據庫集成，很是方便用戶開發，簡單的拖拖拉拉，再連接數據庫，就能搞出一些像樣的東西出來。這對系統邏輯不是很複雜的狀況下，開發簡單高效，且因爲邏輯不是很複雜，也容易維護，因此頗有優點。

可是系統的邏輯一旦達到必定的複雜度，把業務邏輯都放在存儲過程當中就會有2個很大的弊端，一是把系統的壓力全都壓到數據庫上，這樣勢必增長系統的風險，且針對未來的負載增長的時候，不容易作水平擴展；二是業務邏輯放到存儲過程，維護比較困難，且對於一些業務擴展，勢必會增長冗餘的代碼，這樣也會增長系統出bug的風險。

因此，在考量一個設計方案的時候，要綜合系統的複雜度、技術實現平臺等各方面。例如，對於技術實現平臺，.net提供了這種集成數據庫的UI控件，可以有效實現數據驅動，開發簡單高效，但java就沒法提供這種優點(ps:通常把這種叫作【表模塊】設計方式)；對於系統複雜度很高，爲了應付後續的需求，通常會考慮【領域模型】設計方式，經過對業務進行領域建模，利用面向對象的各類設計模式，可以有效知足業務需求，且將系統壓力分流到應用端，經過應用端的水平擴展，更方便系統擴容。

因爲不瞭解大家系統的業務複雜程度，因此也不能說現有的基於存儲過程的設計方式有什麼問題，這須要你根據大家系統的需求等各方面綜合來評估。最後推薦一本書：企業應用架構模式