嵌套視圖是一個好的數據庫設計嗎？

我很久以前在某個地方讀過。這本書指出，我們不應該允許在 SQL Server 中有嵌套視圖。我不確定我們不能這樣做的原因，或者我可能記得錯誤的陳述。

學生

SELECT studentID, first_name, last_name, SchoolID, ... FROM students

CREATE VIEW vw_eligible_student
AS 
SELECT * FROM students
WHERE enroll_this_year = 1

老師

SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers

CREATE VIEW vw_eligible_teacher
AS 
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1

學校

CREATE VIEW vw_eligible_school
AS 
SELECT TOP 100 PERCENT SchoolID, school_name 

FROM schools sh 
JOIN
    vw_eligible_student s 
    ON s.SchoolID = sh.SchoolID
JOIN 
    vw_eligible_teacher t
    ON s.SchoolID = t.SchoolID

在我的工作場所，我調查了我們的一個內部數據庫應用程序。我通過對象檢查發現有兩層或三層視圖相互堆疊。所以這讓我想起了我過去讀過的東西。誰能幫忙解釋一下？

如果這樣做不行，我想知道它僅限於 SQL Server 還是一般用於數據庫設計。

附加資訊：我更新了我公司的一個範例。我在沒有太多技術的情況下進行了一些更改以使其更通用（此範例中的列太多）。我們使用的嵌套視圖大多基於抽像或聚合視圖。例如，我們有一個包含數百列的大型學生表。說，Eligible Student View是基於今年入學的學生。學生符合條件的視圖可以在其他地方使用，例如在儲存過程中。

無論平台如何，以下備註均適用。

(-) 嵌套視圖：

• 更難理解和調試

例如，該視圖列指的是哪個表列？讓我深入了解4 個級別的視圖定義……

• 使查詢優化器更難提出最有效的查詢計劃

有關軼事證據，請參見this、this、this和this。與此相比，這表明優化器通常足夠聰明，可以正確解包嵌套視圖並選擇最佳計劃，但並非沒有編譯成本。

您可以通過將視圖查詢與針對基表編寫的等效查詢進行比較來衡量性能成本。

(+) 另一方面，嵌套視圖讓您：

• 集中和重用聚合或業務規則
• 抽像出您的底層結構（例如，從其他數據庫開發人員那裡）

我發現它們很少需要。

---

在您的範例中，您使用嵌套視圖來集中和重用某些業務定義（例如“什麼是合格的學生？”）。這是嵌套視圖的有效用途。如果您正在維護或調整此數據庫，請權衡保留它們的成本與刪除它們的成本。

• 保留：通過保留嵌套視圖，您會產生上面列舉的優點和缺點。

• 移除：移除嵌套視圖：

  1. 您需要用它們的基本查詢替換所有出現的視圖。
  2. 如果您對合格學生/教師/學校的定義發生變化，您必須記住更新所有相關查詢，而不是僅僅更新相關視圖定義。

引用自：https://dba.stackexchange.com/questions/5487