使用視圖連接表或儲存過程以獲得更好的執行計劃？
首先讓我聲明我是 C# 開發人員，而不是 SQL Server DBA，所以請原諒我對 SQL Server 數據庫查詢執行計劃的無知。
我想知道的是一個儲存過程，它使用主鍵和外鍵從兩個或多個表中提取結果來引用它們，更好的做法是：
- 有一個視圖，它執行連接並包含兩個（或更多）表中所有相應記錄的展平數據，並讓儲存的過程從中選擇並過濾該視圖
- 讓儲存過程進行連接和過濾。
我問是因為在 C# 世界中我們會分離出關注點，所以一個對像或函式將負責加入（在這種情況下是視圖），另一個對像或函式將負責過濾（在這種情況下是儲存過程）。
- 上面的哪個選項會表現得更好？
- 上面的哪個選項被認為是最佳實踐？
在 C# 中，關注點分離通常被認為比性能更重要，直到證明性能已成為程式碼的一個嚴重問題。但我不知道在 SQL 世界裡有哪些東西！
上面的哪個選項會表現得更好？
最好的情況是，兩者都將產生完全相同的執行計劃，並具有相同的執行時性能。
正如 Rob Farley 在他的回答中提到的那樣，這可能需要一些仔細的設計和一些相當先進的技能。Rob 也有一篇描述核心問題的部落格文章，並且在他的SQL Server MVP Deep Dives Volume 1書中的一個章節中也有討論。
上面的哪個選項被認為是最佳實踐？
無論哪種方式，這可能更像是一個既定的最佳實踐，但經驗豐富的數據庫專業人員傾向於將他們對視圖的使用限制在它們提供真正和顯著好處的場景中。視圖變得越複雜（尤其是當視圖開始堆疊或分層時）就越難避免不希望的副作用，並且越有可能遇到優化器限制。
如果查詢引用了視圖，則查詢可能更易於閱讀和維護，但在選擇視圖或在儲存過程中寫出基礎查詢時，您會發現數據庫專業人員不會討論“關注點分離”。程式中有許多既定的實踐和模式不能很好地轉化為數據庫工作。
始終牢記（非索引/物化）視圖只是儲存的查詢定義。它被擴展為引用查詢，就像在查詢編譯和優化開始之前手動複製和粘貼一樣。
您沒有要求對使用視圖的優點和缺點進行全面的批評（無論如何這可能是一個過於寬泛的問題），所以我不會嘗試提供一個。我最後要提醒的是，即使是今天優化得很好的簡單視圖（可能利用了 Rob 的想法）也可以很容易地修改（通常以一種無害的方式），因此引用它們的查詢突然遇到優化器限制和性能懸崖。
我在http://bit.ly/Simplification的演講中展示了一些關於視圖的重要內容 - 關鍵是確保您沒有進行不必要的連接，當您不需要時它們會得到優化列。
我的演講通常涵蓋開發人員介面模組化的想法，因此它可能非常有用。