Question

当我可以使用内部查询轻松解决相同问题时，我发现自己不愿意使用JOIN：

e.g。

SELECT COLUMN1, ( SELECT COLUMN1 FROM TABLE2 WHERE TABLE2.ID = TABLE1.TABLE2ID ) AS COLUMN2 FROM TABLE1;

我的问题是，这是一个糟糕的编程习惯吗？我发现与连接相比，它更容易阅读和维护。

更新

我想补充一点，这里有一些很棒的反馈，实质上是推回使用JOIN。由于ORM解决方案（LINQ to SQL，NHibernate等）的结果，我发现自己现在越来越少地使用TSQL，但是当我这样做时，我发现相关子查询之类的内容更容易线性输入

Answer 1

就个人而言，我发现这非常难以阅读。它不是SQL开发人员期望的结构。通过使用JOIN，您可以将所有表源保留在一个位置，而不是在整个查询中传播它。

如果您需要三个或四个连接会怎样？将所有这些放入SELECT子句将会变得毛茸茸。

Answer 2

连接通常比相关子查询更快，因为它一次作用于行集而不是一行。我永远不会让这些代码进入我的生产服务器。

我发现联接更容易阅读和维护。

Answer 3

如果您需要第二个表中的多个列，则需要两个子查询。这通常不会像加入一样好。

Answer 4

这不等于JOIN。

如果TABLE1中的每一行都包含TABLE1中的每一行，则不会得到它们。对于TABLE1中的每一行，您将得到一行输出，因此您无法从TABLE2中获取多个。

这就是我使用“JOIN”的原因：确保我得到我想要的数据......

更新后：我很少使用相关性，除了EXISTS ...

Answer 5

您使用的查询通常用作LEFT JOIN替代缺少它的引擎（最值得注意的是PostgreSQL之前的7.2）

这种方法有一些严重的缺点：

如果TABLE2.ID不是UNIQUE
对于此查询，某些引擎将无法使用NESTED LOOPS以外的任何内容
如果您需要选择多个列，则需要多次编写子查询

如果您的引擎支持LEFT JOIN，请使用LEFT JOIN。

但是，在MySQL中，在某些情况下，选择级子查询中的聚合函数可能比LEFT JOIN中GROUP BY的聚合函数更有效。

在我的博客中查看以下示例：

Aggregates: subqueries vs. GROUP BY

Answer 6

这对所有IMO来说都不是一个糟糕的编程习惯，但它有点难看。实际上，在子选择来自非常大的表而您期望非常小的结果集（您必须考虑索引和平台，2000具有不同的优化器以及所有来自2005）的情况下，它实际上可以是性能提升。以下是我将其格式化以便于阅读。

select
  column1
  [column2] = (subselect...)
from
  table1

编辑：这当然假设您的子选择只返回一个值，如果不是，它可能会返回不良结果。见gbn的回应。

Answer 7

它使得使用其他类型的连接（左外部，交叉等）变得容易得多，因为子查询中的那些连接的语法不太适合可读性

Answer 8

在一天结束时，编写代码的目标超出了功能要求，目的是使代码的意图对读者清楚。如果你使用JOIN，意图是显而易见的。如果你以你描述的方式使用子查询，那么就会出现为什么你这样做的问题。你想要实现JOIN不会实现的目标是什么？简而言之，你浪费了读者的时间来确定作者是否以巧妙的方式解决了一些问题，或者他们是在经过一夜辛苦的饮酒之后编写代码。

为什么使用JOIN而不是内部查询

8 个答案: