在google搜了下「儲存過程 優劣」關鍵字，資料並不多，出現了一篇關於來至51cto的關於儲存過程的優缺點的文章，具體這裡也不指出了。看見文章中對儲存過程的幾個辯解，個人不敢苟同，個人已經很仔細的看了文章的時間是2023年，如果在更前寫年成的話，個人覺得完全能夠理解。所以有了這篇，儲存過程的一些傳言。
1：儲存過程只在創造時進行編譯，以後每次執行儲存過程都不需再重新編譯，而一般sql 語句每執行一次就編譯一次,所以使用儲存過程可提高資料庫執行速度。
在sql server 2000版本，這個觀點沒錯，卻是如此。但是在sql server2005文件中很清晰的寫到 sql server2005的執行任何sql，關係引擎會首先檢視快取，判斷是有有其執行計畫。如果有，則將會重用該執行計畫，以減少重新編譯sql語句生成執行計畫的影響。包括oracle也是這麼做的，所以在我們常見的資料庫中不存在這所謂的問題。
2：當對資料庫進行複雜操作時(如對多個表進行update,insert,query,delete 時），可將此複雜操作用儲存過程封裝起來與資料庫提供的事務處理結合一起使用。這些操作，如果用程式來完成，就變成了一條條的sql語句，可能要多次連線資料庫。而換成儲存，只需要連線一次資料庫就可以了。
這個問題在前面的架構設計-資料訪問層簡述中說過，dba總是告訴我們減少資料庫連線次數，這是完全無爭議的，我表述很贊同。但是一定是儲存過程的優勢？或者說除了儲存過程就沒其他方式？在架構設計-資料訪問層簡述中介紹了來自martin fowler《p of eaa》的uow（工作單元）模式，定義為工作單元記錄在業務事務過程中對資料庫有影響的所有變化。操作結束後，作為一種結果，工作單元了解所有需要對資料庫做的改變。其主旨是在記憶體中建立乙個和資料倉儲，維護變化的物件，業務物件變化跟蹤，在業務操作完成一次性提交到資料儲存介質，提供業務事務。這模式已經在我們常見的orm（entityframework，nhibernate等）中很好的支援了，或許這麼說這也是orm框架的乙個重要特徵。在比如微軟的dataset也支援，批量更新。
3:儲存過程可以重複使用，可減少資料庫開發人員的工作量。
在專案中我們糜爛的重複**僅僅在於資料層？更多或許在於業務邏輯的處理，複雜的條件判斷，資料操作的組合。儲存過程是由開發人員開發，還是資料庫開發人員？每個公司的資料庫開發人員就僅僅那幾個吧，我見過的公司。儲存過程是否包含業務規則？如果有的話，業務的不停變化，會不會不停的修改關係模型，修改儲存過程，sql的編寫和除錯雖然現在工具有一定的支援，但是我覺得沒有開發語言這麼智慧型方便吧，至少我還沒看見。如果沒有至少簡單的查詢語句，那和普通的sql有什麼差別？減少開發量為什麼不選擇orm之類的動態sql，採用完全的物件模型開發，只在少部分orm失效的業務返璞歸真。
4：如果把所有的資料邏輯都放在儲存過程中，那麼asp.net只需要負責介面的顯示功能，出錯的可能性最大就是在儲存過程。一般情況下就是這樣。公升級、維護方便。
這句話更離譜。邏輯放在儲存過程，便於維護，我也進入過這樣的公司參與過這樣的專案，由於剛開始新員工，不能全盤否定，我看見的是惱人的儲存過程，惱人是sql，沒看過那個開發人員喜歡sql，特別在每次專案需求變更的時候。後來慢慢接受ddd模式，把業務從sql中掙脫出來。asp.net只需要負責介面的顯示功能，邏輯層次未免太簡單了，我猜測這應是 事務性指令碼開發模式，其優劣點在架構設計-業務邏輯層簡述中說過，只能實用於簡單小型的專案。在加上可移植性差，如果你的客戶需要資料庫的公升級，sql server到oracle會怎麼樣。
5：安全性高，可設定只有某此使用者才具有對指定儲存過程的使用權。
安全對於專案來說不僅僅在於資料庫，而應是分布於我們系統各處。安全關注點應該從表現層到資料庫各層之間都應該有處理。一般比較靈活有效基於角色（域）安全和資料庫安全，物理伺服器安全共同使用，這和不適用儲存過程，使用sql並沒什麼衝突。雖然你可能說儲存過程可以作為資料庫內部資源實施安全策越。
6：還有些：儲存過程可以防止sql注入
這個是當然的，毫無爭議。因為用的是引數化方式，你不能隨意拼接字串，引數化方式能夠幫助我們防止大多數的sql注入。在ado.net中為我們提供了很好的引數化支援，使用sql我們同樣可以做到，再加上一切開源的安全元件的過濾。
最後儲存過程並不是萬惡的，他有他的應用場景，對於複雜邏輯如報表的場景，我會毫不猶豫的放棄orm，選擇它，因為orm不能滿足這種複雜查詢，但是準確的說我選擇的是大量的t-sql或者是p-sql，儲存過程就是一堆sql子程式的固定格式。我覺得可以完全採用ibatis.net方式的xml配置，更爽些。選擇儲存過程是由於複雜查詢業務，我相信大家也不會為了一些複雜的統計把全表資料載入到記憶體吧。儲存過程開發技術流行與2005前資料為中心的開發模式，在現在的模式，工具，技術下顯得有些蒼老，但並不是一無是處。你也可以完全採用基於儲存過程的開發模式開發出很好的系統。
軟體架構設計系列總結 9 儲存過程傳言
在google搜了下 儲存過程 優劣 關鍵字，資料並不多，出現了一篇關於來至51cto的關於儲存過程的優缺點的文章，具體這裡也不指出了。看見文章中對儲存過程的幾個辯解，個人不敢苟同，個人已經很仔細的看了文章的時間是2011年，如果在更前寫年成的話，個人覺得完全能夠理解。所以有了這篇，儲存過程的一些傳...
軟體架構設計系列總結
出處 架構引用 維基百科 軟體體系結構是構建 計算機軟體 實踐的基礎。與建築師設定建築專案的設計原則和目標，作為繪圖員畫圖的基礎一樣，乙個 軟體架構師 或者系統架構師 陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。從和目的 主題 材料和結構的聯絡上來說，軟體架構可以和建築物的 架構相比...
軟體架構設計過程
一般軟體的設計過程分為以下幾步 1.概念化階段 2.分析階段 3.架構設計階段 4.並行開發和測試階段 5.驗收與交付階段 架構師的架構設計過程 1.需求分析 2.領域建模 3.確定關鍵需求 4.概念性架構設計 5.細化結構 6.驗證架構 需求分析 主要是對客戶提出的需求的均衡考慮以及隱藏需求的挖掘...