關於儲存過程的優缺點

儲存過程的使用，好像一直是乙個爭論。

我不傾向於盡可能使用儲存過程，是這麼認為的：

1. 執行速度：大多數高階的資料庫系統都有statement cache的，所以編譯sql的花費沒什麼影響。但是執行儲存過程要比直接執行sql花費更多（檢查許可權等），所以對於很簡單的sql，儲存過程沒有什麼優勢。

2. 網路負荷：如果在儲存過程中沒有多次資料互動，那麼實際上網路傳輸量和直接sql是一樣的。

3. 團隊開發：很遺憾，比起成熟的ide，沒有什麼很好儲存過程的ide工具來支援，也就是說，這些必須手工完成。

4. 安全機制：對於傳統的c/s結構，連線資料庫的使用者可以不同，所以安全機制有用；但是在web的三層架構中，資料庫使用者不是給使用者用的，所以基本上，只有乙個使用者，擁有所有許可權（最多還有乙個開發使用者）。這個時候，安全機制有點多餘。

5. 使用者滿意：實際上這個只是要將訪問資料庫的介面統一，是用儲存過程，還是ejb，沒太大關係，也就是說，在三層結構中，單獨設計出乙個資料訪問層，同樣能實現這個目標。

6. 開發除錯：一樣由於ide的問題，儲存過程的開發除錯要比一般程式困難（老版本db2還只能用c寫儲存過程，更是乙個災難）。

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

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

從上面可知道，儲存過程的使用不能有死規定（全用，或全不用），以前terminal - server, client-db的方式已經過時了，儲存過程很多優勢已經不明顯。

現在，我認為的原則是：所有資料訪問在應用層封裝為資料訪問層，在那裡，如果sql簡單的話，直接用sql；如果sql複雜，或者資料互動多且中間資料最後不會用到，使用儲存過程。其他憑經驗吧。