我针对 Oracle 数据库进行开发。当我需要手动编写时（不使用像 hibernate 这样的 ORM），我使用 WHERE 条件而不是 JOIN。
例如（这只是为了说明风格而简单化）：
Select *
from customers c, invoices i, shipment_info si
where c.customer_id = i.customer_id
and i.amount > 999.99
and i.invoice_id = si.invoice_id(+) -- added to show a replacement for a join
order by i.amount, c.name
我从一个老的 oracle DBA 那里学到了这种风格。从那以后，我了解到这不是标准的 SQL 语法。除了不标准和数据库可移植性差之外，使用这种格式还有其他影响吗？
【问题讨论】：
旧式连接在某些情况下是完全错误的（外部连接是罪魁祸首）。尽管在使用内连接时它们或多或少是等价的，但外连接可能会产生不正确的结果，尤其是在外侧的列可以为空的情况下。这是因为当使用较旧的语法时，在构造整个结果集之前不会在逻辑上评估连接条件，根本不可能从连接外侧的列上表达一个条件：当列可以为空时将过滤记录，因为没有匹配的记录。
举个例子：
选择 所有 客户，以及在 8 月份处理发票的所有发票上的小部件销售额总和（Invoice.ProcessDate 为不空）
使用新的 ANSI-92 连接语法
Select c.name, Sum(d.Amount)
From customer c
Left Join Invoice I
On i.custId = c.custId
And i.SalesDate Between '8/1/2009'
and '8/31/2009 23:59:59'
And i.ProcessDate Is Not Null
Left Join InvoiceDetails d
On d.InvoiceId = i.InvoiceId
And d.Product = 'widget'
Group By c.Name
尝试使用旧语法执行此操作...因为当使用旧样式语法时，where 子句中的所有条件都在重新添加“外部”行之前评估/应用，所有未处理的发票行都将被添加回到最终结果集...所以这对于旧语法是不可能的 - 任何试图过滤出具有空处理日期的发票的任何事情都会消除客户......唯一的选择是使用相关子查询。
【讨论】：
我后来了解到这不是标准的 SQL 语法。
这并不完全正确。 "a,b where" 语法来自 ansi-89 标准，"a join b on" 语法是 ansi-92。但是，89 语法已弃用，这意味着您不应该将其用于新查询。
此外，在某些情况下，旧样式缺乏表达能力，尤其是在外连接或复杂查询方面。
通过 where 子句尝试挑选连接条件可能会很痛苦。对于任何多于一个的东西，旧风格都是绝对的邪恶。一旦你知道了新的风格，你也可以继续使用它。
【讨论】：
这真的取决于习惯，但我一直发现 Oracle 的逗号分隔语法更自然。第一个原因是我认为使用 (INNER) JOIN 会降低可读性。第二是关于灵活性。最后，根据定义，连接是笛卡尔积。您不必根据两个表的 ID 来限制结果。虽然很少见，但很可能需要两张表的笛卡尔积。根据 ID 限制它们只是一种非常合理的做法，但不是规则。但是，如果您使用 JOIN 关键字，例如SQL Server，它不会让你省略 ON 关键字。假设您要创建一个组合列表。你必须这样做：
SELECT *
FROM numbers
JOIN letters
ON 1=1
除此之外，我觉得Oracle的(+)语法也很合理。这是一个很好的说法，“也将这条记录添加到结果集中，即使它是空的。”它比 RIGHT/LEFT JOIN 语法要好得多，因为其实没有左右之分！当你想用几种不同类型的外连接连接 10 个表时，会混淆哪个表在“左侧”，哪个在右侧。
顺便说一句，作为更一般的评论，我认为 SQL 可移植性在实际世界中不再存在。标准的 SQL 太差了，而且经常需要各种 DBMS 特定语法的表达能力，我不认为 100% 可移植的 SQL 代码是一个可以实现的目标。我观察的最明显证据是旧的行号有问题。只需在任何论坛中搜索“sql 行号”，包括 SO，您就会看到数百篇询问如何在特定 DBMS 中实现它的帖子。与此类似并与之相关，例如，限制返回的行数也是如此。
【讨论】：
只要你不使用 ANSI 自然连接功能，我就可以。
我发现了这句话 – ScottCher，我完全同意：
我发现 WHERE 语法比 INNER JOIN 更容易阅读 - 我猜它就像 Vegemite。世界上大多数人可能觉得它很恶心，但长大后吃它的孩子们喜欢它。
【讨论】：
这是一个标准的 SQL 语法，只是一个比 JOIN 更旧的标准。语法已经发展是有原因的，您应该使用更新的 JOIN 语法，因为：
更具表现力，清楚地指出了哪些表被 JOIN，JOIN 顺序，哪些条件适用于哪些 JOIN，并将过滤 WHERE 条件与 JOIN 条件分开。
它支持 LEFT、RIGHT 和 FULL OUTER JOIN，而 WHERE 语法不支持。
我认为您不会发现 WHERE 类型的 JOIN 的可移植性远低于 JOIN 语法。
【讨论】：
我不喜欢这种风格，因为它使确定哪些WHERE 子句用于模拟JOINs 以及哪些子句用于实际过滤器变得更加困难，而且我不喜欢使确定变得不必要的困难的代码程序员的初衷。
【讨论】：
我在使用这种格式时遇到的最大问题是倾向于忘记某些连接的 WHERE 子句，从而导致笛卡尔积。在向查询中添加新表时，这尤其常见（至少对我而言）。例如，假设有一张ADDRESSES 的桌子被扔进了混合物中，而你的大脑有点健忘：
SELECT *
FROM customers c, invoices i, addresses a
WHERE c.customer_id = i.customer_id
AND i.amount > 999.99
ORDER BY i.amount, c.name
轰隆隆！笛卡尔积！ :)
【讨论】：
这是 Transact SQL 语法，我不太确定它有多“不可移植” - 例如，它是 Sybase 中使用的主要语法（Sybase 也支持 ANSI 语法）以及许多其他数据库（如果不是全部）。
ANSI 语法的主要好处是它允许您编写一些 T-SQL 禁止的相当棘手的链式连接
【讨论】：
实际上，这种语法比 JOIN 更更可移植，因为它几乎适用于任何数据库，但并不是每个人都支持 JOIN 语法（例如，Oracle Lite 不支持 [除非这最近发生了变化])。
【讨论】：
有些人会说这种风格可读性较差，但这是习惯问题。从性能的角度来看，这并不重要，因为查询优化器会处理这个问题。
【讨论】：