SQL視圖和Sprocs

Question

我制定了一項公司政策，所有數據訪問都必須通過Sprocs完成。這包括選擇，更新，刪除和插入。我們開始被他們超越。我是否過度使用它？選擇正在執行，並且結果轉儲到自定義的DAL中。

我有一種感覺，這是一個神聖的戰爭類型的問題。我傾向於認爲sprocs對於簡單的選擇是過度的，但是更新，插入和刪除的必要性。 sprocs的一個參數是安全性。某些用戶不應該有權訪問應用程序的某些部分。誰在這裏實際創建一個以上的用戶在一個網站的分貝？沒有手？

我還需要檢索有關多個表的統計信息。這是一個查詢與UDF的一些調用。這些統計數據按分鐘變化。我應該使用視圖還是存儲過濾器？我正在學習一個小貼子，因爲無論如何，這個視圖只需要重建自己。這是一個正確的假設嗎？

Answer 1

除了存儲過程，您可以允許訪問視圖。您仍然可以控制對視圖的訪問，但一個視圖可以替代許多存儲過程。

您還可以按功能對存儲過程進行分組，併爲每個組使用一個前綴。像，cart_AddItem或user_GetPreferences。這是追溯性實施的很多工作，但從未太遲。

如果您要維護可由多個程序和/或網站訪問的數據庫，那麼存儲過程是我知道的保持複雜性可管理性的唯一途徑。另一方面，如果它只是一個單獨的網站，像數據訪問層這樣的LINQ可以很好地工作。

Answer 2

好吧，這會讓我聽起來像我是一個混蛋，但我真的不是故意的。我對你的問題的回答是另一個問題。

「做什麼業務，你已經定義 發展的政策，如果你不明白 數據庫是如何工作的？」

你說「這個觀點每次都要重建自己」。你是說任何有視圖的代碼在每次查詢時都會被重新編譯嗎？因爲這絕對不是真的，（至少在Oracle和SQL Server上是這樣）。使用視圖是一種比存儲過程更靈活的方式來獲得高效的查詢，因爲優化器可以按照使用方式重新優化視圖。一旦完成了，查詢計劃就被緩存起來，所以不需要重新編譯。案例：創建這樣的觀點：

然後，您決定要將所有客戶的列表名爲John Smith：

SELECT c.CustomerID 
FROM myOrders 
WHERE c.LastName = 'Smith' AND c.FirstName = 'John'; 

因爲它是一個觀點，加入到「訂單」獲得優化了。如果您試圖在存儲過程中對此進行模塊化，那麼您不能。你可能不得不爲另一個目的製作另一個貼片。很快你就會遇到你所遇到的問題，這是一大堆幾乎不可維護的過程。

爲什麼使用存儲過程？你想解決什麼問題？封裝？我認爲對於SELECT來說，UDF可能更有用。我也會爭辯說，中間層的LINQ類型查詢更加靈活。你是否試圖通過使用存儲過程來優化性能？如果是這樣，請了解並瞭解您運行的每個即席查詢都會得到優化和緩存。如果您使用SQL Server 2005+，甚至可以強制它參數化並緩存查詢計劃，即使您沒有明確指定參數。

存儲過程有它們的位置，但是它們的可維護性，使用靈活性以及是，甚至性能的缺點意味着您應該明智地使用它們，而不是爲開發人員制定一攬子策略。