尷尬的存儲過程

? ? ? 最近在給一個已沉淀了多年的系統框架進行優化，發現大部分的基礎業務（比如增刪改）的實現都是通過存儲過程來實現。這讓我糾結了很久，看了下代碼格式我猜應該都是使用了代碼生成器。這無疑為系統的擴展留下了一個難以彌補的大坑。

? ? ? 首先一定要搞明白為什么會有“存儲過程”這個東西。如果我們使用程序訪問數據庫(比如 java 中的 jdbc、.net 中的 ado.net )，?正常情況是程序連接數據庫服務器,然后向數據庫服務器發送執行 SQL語句。 由于程序和數據庫服務器之間的 SQL 執行過程其實就是網絡通訊的過程，但網絡通訊有時穩定性并不理想。如果一個業務操作要執行很多條 SQL 語句或執行一個 SELECT 查詢時，遍歷查詢結果的時候又要執行其他sql語句進行其他操作的時候，在程序和數據庫服務器之間就會頻繁的進行網絡交互，這樣數據庫服務器的壓力會比較大,而且速度慢。這時候如果把這些業務邏輯寫到一個存儲過程,由于存儲過程是運行在數據庫服務器內的,這樣只要程序向數據庫服務器請求一次“運行某某存儲過程”,剩下的就是在數據庫服務器內部執行了,因此運行速度會快一些,而且并發壓力會小一些。這是我們使用 “存儲過程”這個東西的初衷。

? ? ? 上述我想應該很清晰的能夠明白為什么需要使用存儲過程了，所以基于這種情況我們就不需要連最基礎的增刪改都使用存儲過程了。

? ? ? 另外,現在業界的共識是“盡可能的不用存儲過程”,因為存儲過程在不同數據庫中的語法是不一樣的,跨數據庫移植很麻煩,還有存儲過程很難和項目之間完美的進行源碼版本管理,因此除了在一些極特殊的情況下,否則不要使用存儲過程。

?