1

我有一个查询，它从原始数据源顺序连接 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 的预期用途（也是我不使用视图的原因），因为每个定义实际上只按顺序引用一次。

有没有关于如何构建这样的顺序嵌套连接的指导，这种连接在结构上既可读又合乎逻辑？

4

3 回答 3

1

我认为利用 CTE 创建临时视图没有任何问题。

  1. 在较大的商店中，定义了角色，将 DBA 与开发人员的职责分开。一般来说，CREATE 语句将成为这种官僚主义的牺牲品。因此，没有看法。CTE 是一个很好的折衷方案。
  2. 如果视图无论如何都不是真正可重用的，那么将其与 SQL 一起保存会使其更具可读性。
  3. CTE 比子查询（即使只有一层）更具可读性和直观性。如果您的子查询不相关，我只是建议将您的所有子查询转换为 CTE。
  4. 递归是 CTE 的“杀手”应用程序，但这并不意味着您不应该使用 CTE，否则。

我能想到的唯一缺点是（取决于您的数据库引擎）它可能会混淆或阻止优化器执行它应该执行的操作。优化器足够聪明，可以为您重写子查询。

现在，让我们讨论一下 CTE 的滥用，注意不要用应用程序开发人员的知识代替数据库引擎优化。有很多聪明的开发人员（比我们更聪明）设计了这个软件，尽可能多地编写不带 cte 或子查询的查询，让 DB 完成工作。例如，我经常看到开发人员在进行联接之前对子查询中的每个键进行 DISTINCT/WHERE。你可能认为你在做正确的事，但事实并非如此。

关于您的问题，大多数人打算解决问题而不是讨论理论问题。因此，你会让人们对你所追求的东西摸不着头脑。我不会说你在你的文字中没有暗示，但也许更有力。

于 2012-10-28T18:00:00.750 回答
0

你为什么不像这样加入你的桌子

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>
于 2012-10-28T18:19:00.277 回答
0

可能是我不明白这个问题，但有什么问题：

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 ....

于 2012-10-26T23:42:57.847 回答