使用視圖編寫查詢是一個好策略嗎？

Question

我只想知道是否通過首先在視圖中創建查詢來編寫查詢是否正確。

有什麼建議嗎？

Answer 1

查詢視圖通常是可以的，因爲sql服務器優化器不容易上當。但是不要在你的視圖中使用標量函數，否則你會遇到性能問題。

Answer 2

這取決於你在視圖中做什麼，以及你打算如何處理它們。

創建視圖，然後將它們層疊在一起（通過引用另一個視圖中的視圖）通常不是一個好主意。在視圖中使用ORDER BY也是一個普遍的否定，因爲如果你加入視圖 - 按順序執行，但不需要它。

Answer 3

視圖是一個宏，並且是expanded。

視圖之上的視圖僅僅意味着更多的工作讓優化器解開下面的複雜性。

Answer 4

在一天結束時，視圖只是一個子查詢，所以它真的沒什麼大不了的。

SELECT * 
FROM (
    SELECT * 
    FROM myTable 
    WHERE a = 2 
) a 

無異於是

SELECT * 
FROM myView 

該計劃被緩存，因此你真的不遭受任何性能影響，你會得到重用你的代碼是其他的靈活性。

Answer 5

我知道有一個school of thought表示你應該有一個每張表的視圖，並根據你的視圖而不是你的表開發你的代碼。在這種情況下，您可以使用演化開發方法，並且在修改表格時爲新代碼開發新視圖，而不會破壞舊代碼依賴的視圖。我從來沒有真正有過一個我認爲會很複雜的項目，所以我不能隨着表格的更改而更新代碼，所以我從來沒有使用過這種方法。

至於寫入查詢視圖有一種情況下，我這樣做。但是，它們可能是特定於我使用LINQ的，因此請帶上一點鹽。如果我有一個查詢需要一些複雜的處理並返回一個基於多個表的複合對象，我通常會編寫一個存儲過程或表值函數來執行查詢。我發現使用LINQ設計器最簡單，如果我還創建了一個視圖，我可以拖放到設計界面上爲sp /函數返回的對象創建類，而不是讓它自動生成類。如果我選擇的話，它給了我更多的對命名類的控制權。