存儲過程的優缺點

聊起存儲過程的優缺點一貫的風格是旱的旱死澇的澇死，各執一詞。

就我們正方觀點來看，存儲過程有著‘絕對’的優勢： 

1. 首先存儲過程可以減少它的網絡通信量，相對于復雜的邏輯來講，它既可以無需過多的筆墨對查詢數據進行總（聯表查詢） 分（邏輯處理）總（數據整合）的繁雜操作，在輸出結果之前即可實現相關數據的整合處理。其性能絕對比一條一條的調用SQL語句要高的多。且筆落則數據出。

2. 它的邏輯處理清晰簡單，存儲過程說白了就是 一堆SQL 的合并。中間加了點邏輯控制。邏輯處理在你考慮幾十行代碼最優解的時候，可能別人已經通過簡單的十幾行存儲過程解決了。且充分利用了db本身的優勢，執行速度更快。在存儲過程創建的時候，數據庫已經對其進行了一次解析和優化。其次，存儲過程一旦執行，在內存中就會保留一份這個存儲過程，這樣下次再執行同樣的存儲過程時，可以從內存中直接調用。它是個不容易犯錯，且讓個人能力差距縮小，編碼速度提升的可行辦法。

3.它具有超強的適應性，且開發人員承接更為容易。由于存儲過程對數據庫的訪問是通過存儲過程來進行的，因此數據庫開發人員可以在不改動存儲過程接口的情況下對數據庫進行任何改動，而這些改動不會對應用程序造成影響。同樣在接手別人代碼的時候，不過是接手一個具備功能的'輪子'，其本身只是一堆sql語句，談不上思想的碰撞，更不會因為思路不同導致不理解或者難以理解的問題。

4.它甚至可以作為簡易的中臺使用，數據以及適當的邏輯處理提交通過存儲過程，其余的由程序處理，分布式工作。

5.它可以通過傳入參數不同實現動態sql語句去查詢不同的表數據，對于不同的表但是邏輯基本相同的數據需求可以通過傳輸不同的參數實現接口的合并。使得邏輯進一步精簡和清晰化。起碼這一點應該受到python相關的同仁的認同（我以為）。

原文理解是：使用存儲過程使您能夠增強對執行計劃的重復使用，由此可以通過使用遠程過程調用 (RPC) 處理服務器上的存儲過程而提高性能。RPC 封裝參數和調用服務器端過程的方式使引擎能夠輕松地找到匹配的執行計劃，并只需插入更新的參數值。

6.可維護性高（相對的），更新存儲過程通常比更改、測試以及重新部署程序集需要較少的時間和精力。ps : 當你的存儲過程寫滿了整個數據庫，即使你有很好的命名和備注，也逃不開在'亂花'中取一支的命運。不過更改起來的舒適度十分。

7. 更好的版本控制。 看你存儲過程后面的標識就知道了。

當然，我們可愛又迷人的反派角色肯定是要上場的。存儲過程也有著它‘天大’的缺陷：

ps : 以至于我同事十分之反感用此方法去實現任何功能。 其最靈魂的拷問就是： 你能學到個啥？

1. 運行速度。 因為存儲過程終究還是需要整合這些sql，它需要設計檢查權限等，比直接執行sql花費更多。盡管它省略了預編譯的過程，但是大多數高級的數據庫系統都有statement   cache的，所以編譯sql的花費沒什么影響。所以對于很簡單的sql，存儲過程沒有什么優勢。甚至有一點點小扣分（當然，幾乎無視。）

2. 網絡負荷：如果在存儲過程中沒有多次數據交互，那么實際上網絡傳輸量和直接sql是一樣的。 

3. 團隊開發：很遺憾，比起成熟的IDE，沒有什么很好存儲過程的IDE工具來支持，也就是說，這些必須手工完成。（商機哦）

4. 安全機制：對于傳統的C/S結構，連接數據庫的用戶可以不同，所以安全機制有用；但是在web的三層架構中，數據庫用戶不是給用戶用的，所以基本上，只有一個用戶，擁有所有權限（最多還有一個開發用戶）。這個時候，安全機制有點多余。 

5. 用戶滿意：實際上這個只是要將訪問數據庫的接口統一，是用存儲過程，還是EJB，沒太大關系，也就是說，在三層結構中，單獨設計出一個數據訪問層，同樣能實現這個目標。    

6. 開發調試：一樣由于IDE的問題，存儲過程的開發調試要比一般程序困難（老版本DB2還只能用C寫存儲過程，更是一個災難）。  

7.移植性：算了，這個不用提，反正一般的應用總是綁定某個數據庫的，不然就無法靠優化數據庫訪問來提高性能了。    

8. 維護性：的確，存儲過程有些時候比程序容易維護，這是因為可以實時更新DB端的存儲過程，但是在3層結構下，更新server端的數據訪問層一樣能實現這個目標，可惜現在很多平臺不支持實時更新而已。    

反正綜上所述，于我聽起來就是，存儲過程沒有更好，不熟練的話，維護更麻煩。emm，不過博主的一句話我認同：

存儲過程的使用不能有死規定（全用，或全不用）。現在，我認為的原則是：所有數據訪問在應用層封裝為數據訪問層，在那里，如果SQL簡單的話，直接用SQL；如果SQL復雜，或者數據交互多且中間數據最后不會用到，使用存儲過程  。