是否應該使用存儲過程？

在許多關係型數據庫教材中，都推薦使用存儲過程，並列舉種種好處。好比如下來自微軟官方文檔的解釋：

使用存儲過程的好處 下表介紹了使用過程的一些好處。 減小了服務器/客戶端網絡流量 過程當中的命令做爲代碼的單個批處理執行。 這能夠顯著減小服務器和客戶端之間的網絡流量，由於只有對執行過程的調用纔會跨網絡發送。 若是沒有過程提供的代碼封裝，每一個單獨的代碼行都不得不跨網絡發送。 更強的安全性 多個用戶和客戶端程序能夠經過過程對基礎數據庫對象執行操做，即便用戶和程序對這些基礎對象沒有直接權限。 過程控制執行哪些進程和活動，而且保護基礎數據庫對象。 這消除在了單獨的對象級別授予權限的要求，而且簡化了安全層。 可在 CREATE PROCEDURE 語句中指定 EXECUTE AS 子句以便實現對其餘用戶的模擬，或者使用戶或應用程序無需針對基礎對象和命令的直接權限，便可執行某些數據庫活動。 例如，某些操做（如 TRUNCATE TABLE）沒有可授予的權限。 若要執行 TRUNCATE TABLE，用戶必須對指定表具備 ALTER 權限。 授予用戶對錶的 ALTER 權限可能不是最佳方法，由於用戶將擁有超出截斷表的能力的權限。 經過將 TRUNCATE TABLE 語句歸入模塊中並指定該模塊做爲一個有權修改表的用戶執行，您能夠將截斷表的權限擴展至授予其對模塊的 EXECUTE 權限的用戶。 在經過網絡調用過程時，只有對執行過程的調用是可見的。 所以，惡意用戶沒法看到表和數據庫對象名稱、嵌入本身的 Transact-SQL 語句或搜索關鍵數據。 使用過程參數有助於避免 SQL 注入攻擊。 由於參數輸入被視做文字值而非可執行代碼，因此，攻擊者將命令插入過程內的 Transact-SQL 語句並損害安全性將更爲困難。 能夠對過程進行加密，這有助於對源代碼進行模糊處理。 有關詳細信息，請參閱 SQL Server Encryption。 代碼的重複使用 任何重複的數據庫操做的代碼都很是適合於在過程當中進行封裝。 這消除了沒必要要地重複編寫相同的代碼、下降了代碼不一致性，而且容許擁有所需權限的任何用戶或應用程序訪問和執行代碼。 更容易維護 在客戶端應用程序調用過程而且將數據庫操做保持在數據層中時，對於基礎數據庫中的任何更改，只有過程是必須更新的。 應用程序層保持獨立，而且沒必要知道對數據庫佈局、關係或進程的任何更改的狀況。 改進的性能 默認狀況下，在首次執行過程時將編譯過程，而且建立一個執行計劃，供之後的執行重複使用。 由於查詢處理器沒必要建立新計劃，因此，它一般用更少的時間來處理過程。 若是過程引用的表或數據有顯著變化，則預編譯的計劃可能實際上會致使過程的執行速度減慢。 在此狀況下，從新編譯過程和強制新的執行計劃可提升性能。

我的猜想這個觀點是從傳統OLTP系統性能優化的角度考慮的。因爲OLTP的操做每每須要短平快，傳輸的數據量不大。好比須要返回的一行記錄可能只有幾十個字節，不用存儲過程的話，爲了獲取這幾十個字節卻須要向服務器發送1KB甚至更長的SQL語句，性價比實在太不理想。固然也有代碼邏輯重用，執行計劃重用等等其它方面的考慮，在此先不討論。

可是在OLAP系統中，一條SQL語句每每會返回大量數據，並運行較長時間。這種狀況下，是否使用存儲過程對性能的影響就顯得不那麼明顯。並且要注意的是，實際項目開發決策須要參考不少方面，性能只是各類因素其中之一。使用存儲過程的話，開發過程當中常常碰到如下比較頭痛的問題：

1. 搞不清調用這個存儲過程的是哪一個SSIS包，哪一個SSRS報表，哪一個SSAS數據視圖，哪一個程序塊。一旦存儲過程須要更改，很難快速查清受影響的範圍。有的項目有本身的方法來解決這個問題，好比採用特定的命名規則之類的，然而很是高效通用的辦法仍是比較少見。
2. 雖然將數據庫代碼加入源代碼管理是比較推薦的作法，但仍然有許多項目因爲種種客觀條件的限制難以作到這一點（抱歉，這樣說有點籠統，請自行體會）。在這樣的狀況下，存儲過程代碼每每失於管理，不知道誰在何時修改了哪些存儲過程的哪些地方。這些問題的一個典型特徵是在編碼行爲上間接對項目組成員產生難以察覺的影響，例若有些人會造成「將舊代碼註釋掉並保留」的習慣以便於將來察看代碼的舊貌，有些人會在修改存儲過程以前備份數據庫，有些人則喜歡在修改存儲過程前建立一個副本。。。這些行爲的根本問題，正是因爲沒有對存儲過程進行源代碼管理。
3. 許多小型項目缺少嚴謹的權限管理，不能刪除不能修改的存儲過程經常被意外地刪除或者修改。

特別是對於長期的開發項目，代碼管理的重要性每每大於對性能的需求。所以我認爲，針對上述問題，在OLAP環境中，一方面應該堅持將數據庫代碼加入源代碼管理，另外一方面應該將SQL語句直接寫在調用方代碼裏以便追蹤代碼變動的影響。

 

歡迎加入SQL Server精英羣參與技術交流