sql - 自然连接——关系理论和 SQL

Question

这个问题来自于我对 C.J Date 的SQL 和关系理论:如何编写准确的 SQL 代码的阅读，以及在互联网上查找有关联接的信息(其中包括在此处遇到多篇有关 NATURAL JOIN 的帖子(以及 SQL Server 缺乏对其的支持))

这就是我的问题...

一方面，在关系理论中，自然连接是唯一应该发生的连接(或者至少是高度首选的连接)。

另一方面，在 SQL 中，建议不要使用 NATURAL JOIN，而是使用替代方法(例如带限制的内连接)。

这些内容的协调是否:

• 自然连接在真正的 RDBMS 中工作。然而，SQL 无法完全再现关系模型，而且流行的 SQL DBMS 都不是真正的 RDBMS。

和/或

• 良好/更好的表设计应该消除/最大限度地减少自然连接产生的问题。

？

Answer 1

关于您的问题的一些要点(即使我担心我没有真正回答您提出的任何问题)，

“一方面，在关系理论中，自然连接是唯一应该发生的连接(或者至少是高度首选的连接)。”

这似乎表明您将理论解释为禁止“其他类型”的连接......事实并非如此。关系理论并没有说“你不能有反连接”，或者“你永远不应该使用反连接”，或者类似的东西。它所说的是，在关系代数中，可以识别一组原始运算符，其中自然连接是唯一的“类连接”运算符。所有其他“类连接”运算符始终可以用定义的原始运算符等效地表示。例如，笛卡尔积是自然连接的一种特殊情况(其中公共(public)属性集为空)，并且如果您想要两个表的笛卡尔积，这两个表确实具有共同的属性名称，您可以使用 RENAME 解决此问题。例如，半连接是第一个表与第二个表上的一些投影的自然连接。例如，反连接(Date 书中的 SEMIMINUS 或 NOT MATCHING)是第一个表与两个表的 SEMIJOIN 之间的关系差异。等等等等

“另一方面，在 SQL 中，建议不要使用 NATURAL JOIN，而是使用替代方法(例如带限制的内连接)。”

哪里有这样的建议？在 SQL 标准中？我真的不这么认为。区分 SQL 语言本身(由 ISO 标准定义)和该语言的某些(/任何)特定实现(由某个特定供应商构建)非常重要。如果 Microsoft 建议其客户不要在 SQL Server 200x 中使用 NJ，那么该建议与某人不要在 SQL 中完全使用 NJ 的建议具有完全不同的含义。

“自然连接在真正的 RDBMS 中起作用。然而，SQL 无法完全复制关系模型，并且流行的 SQL DBMS 都不是真正的 RDBMS。”

虽然 SQL 本身确实未能忠实地遵守关系理论，但这实际上与 NJ 的问题没有多大关系。

实现是否能够为 NJ 的调用提供良好的性能，是实现的特征，而不是语言的特征，或者是 NJ 的“真实程度”的特征。 “RDBMS”中的“R”。构建不使用 SQL 的 TRDBMS 非常容易，但这给 NJ 带来了荒谬的执行时间。 SQL 语言本身具有支持 NJ 所需的一切。如果实现支持NJ，那么NJ也将在该实现中工作。是否提供良好的性能，是该实现的一个特征，某些特定实现的较差性能不应该“外推”到其他实现，或者被视为 SQL 语言本身的特征。

“好的/更好的表设计应该消除/最小化自然连接产生的问题。”

自然连接会产生问题吗？通过在所需的列上添加显式投影(并根据需要重命名)，可以轻松控制出现在联接参数中的列。就像您也想尽可能避免 SELECT * 一样，出于基本相同的原因......