嵌套語句和CTE的查詢設計

Question

我有一個查詢，該查詢從其原始數據源開始順序連接6個表。 嵌套，一團糟：

SELECT
FROM
(
    SELECT
    FROM
    (
        SELECT
        FROM
        (. . .)
        INNER JOIN
    )
    INNER JOIN
)

我切換到CTE定義，每個定義都是在先前定義上的一個連接，最后的最終查詢提供了結果：

WITH
Table1 (field1, field2) AS
(
    SELECT
    FROM 
    INNER JOIN
),

Table2 (field2, field3) AS
(
    SELECT
    FROM Table1
    INNER JOIN
), . . . 

SELECT 
FROM Table 6

這更具可讀性，並且依存關系按邏輯順序向下流動。 但是，這似乎不像CTE的預期用途（這也是為什么我不使用Views的原因），因為每個定義實際上僅按順序引用一次。

關於如何構造順序可讀且結構合理的嵌套連接，是否有任何指南？

Answer 1

我認為利用CTE創建臨時視圖沒有任何問題。

1. 在較大的商店中，定義了將DBA和開發人員的責任分開的角色。 通常，CREATE語句將成為此官僚機構的受害者。 因此，沒有觀點。 CTE是一個很好的折衷方案。
2. 如果無論如何這些視圖都不是真正可重用的，則將其與SQL保持在一起將使其更具可讀性。
3. CTE比子查詢（即使只有一個級別）也更具可讀性和直觀性。 如果您的子查詢不相關，我建議您將所有子查詢轉換為CTE。
4. 遞歸是CTE的“殺手級”應用程序，但這並不意味着您不應該使用CTE。

我能想到的唯一弊端是（取決於您的數據庫引擎）它可能會混淆或阻止優化器執行應做的事情。 優化器足夠聰明，可以為您重寫子查詢。

現在，讓我們討論CTE的濫用問題，請注意不要將應用程序開發人員的知識替換為數據庫引擎優化。 設計此軟件的有很多聰明的開發人員（我們更聰明），只需編寫不帶cte或子查詢的查詢，並盡可能讓DB完成工作。 例如，我經常看到開發人員在進行聯接之前將DISTINCT / WHERE放在子查詢中的每個鍵上。 您可能認為自己做對了，但事實並非如此。

關於您的問題，大多數人都打算解決問題，而不是在理論上進行討論。 因此，您會讓人們為所追求的東西撓頭。 我不會說您不是在您的文字中暗示這一點，但也許會更有力。

Answer 2

可能是我聽不懂問題，但出了什么問題：

select * from table1 t1, table2 t2, table3 t3, table4 t4, table5 t5, table6 t6 
where t1.id = t2.id and t2.id = t3.id and  t3.id = t4.id 
  and t4.id = t5.id and t5.id = t6.id

或使用table 1 t1 INNER JOIN table2 t2 ON t1.id = t2.id ....

Answer 3

你為什么不只是像這樣加入你的桌子

select *
from Table1 as t1
    inner join Table2 as t2 on t2.<column> = t1.<column>
    inner join Table3 as t3 on t3.<column> = t2.<column>
    inner join Table4 as t4 on t4.<column> = t3.<column>
    inner join Table5 as t5 on t5.<column> = t4.<column>
    inner join Table6 as t6 on t6.<column> = t5.<column>