1）昨天我被要求删除SQL Server数据库中的所有数据，但某些基线系统数据除外。几个月前，请求者（不是我的老板）有大约八个用于此任务的脚本。显然没有人想过编写数据模型或系统数据的脚本。
这个人已经建立了过度复杂的模式，所以我试图了解任务的原因和最终目标。我也很难理解为什么她总是会遇到各种模糊的错误，需要所有这些额外的脚本来“删除并重新添加约束”。
我非常愿意做任何必要的事情，我们谈了几分钟。出于显而易见的原因，我认为寻求理解为什么是好事。突然，她决定自己做这件事要快一点，而不是花时间向我解释这一切，然后我又回到了我的其他工作而没有想到更多。
不知何故，这被解释为负面。
2）几个星期前，在我的第一周，我被要求合并来自另一个系统的一些数据。我获得了600多行SQL脚本，这些脚本似乎都很重要，同时还有一些关于糟糕数据和原始程序员的口头故事。当然需要花费一些时间才能密切关注，但几天后我的最终结果显示为大约25行的简单MERGE。
我已经写了十多年的SQL了，我认为自己在该领域有一些专业知识。当我剥离不必要的复杂层时，我的同事变得有点不耐烦了，我迟到了完成承诺的任务。
我不确定他们是否愿意接受问题的解决方案似乎只是一个非常短暂的命令，我想知道我是否遗漏了一些令人尴尬的事情。不幸的是，我的所有探究性问题都反复遇到了贫困老师给一个过于好奇的小学生带来的那种不屑一顾的非答案。所以我在一封电子邮件中发送了查询并回家了。
第二天早上，我被告知（与＃1同一个人），这一切都是错的，但这是我不可能被认为是新人的东西。她解释说她不得不限制自己重写一切。她的一个观点是关于我已经打算向她询问的关于我自己的数据的一些小问题。另一个是纯粹的SQL。
采用典型的左外连接方案。我们都知道表格的顺序非常重要，例如 Q1 和 Q2 不等同：
SELECT A.x, B.y FROM A LEFT OUTER JOIN B ON A.id = B.id -- (Q1)
SELECT A.x, B.y FROM B LEFT OUTER JOIN A ON B.id = A.id -- (Q2)
当我从概念上思考多个连接时，通常我很自然地想象将新表作为感兴趣的对象，然后描述它的行如何与之前的相关。保持条款并行对我没有任何好处，而且按照我自己的习惯，我通常用这种方式写连接条件：
SELECT A.x, B.y FROM A LEFT OUTER JOIN B ON B.id = A.id -- (Q3)
所以我发现自己正在接受关于表的顺序如何在外连接中起作用的辅导。我曾经以为在求职面试中已经完成了我的智力测试。当我意识到她只关注平等比较时，我的困惑变成了昏迷。对她 Q3 是错误的， Q1 是我需要的版本。
我在外交上坚称它根本没有任何区别，如果她愿意，我可以很容易地证明我的情况。我试图澄清她的推理，但这是一个不仔细倾听你的问题的人，无论他们用多么细致的措辞或用多少技术词来表示一点点的能力，所以我决定我只是无法说服她我不是白痴。我同意改变剧本，因为它不值得辩论。
我想不会立刻吞下我的骄傲，这表明我不是“可以接受的”。
至于风格本身，我遵守雇主喜欢的任何标准，尽管他们的SQL在其他方面经常是草率的。我确实认识到使用旧式外连接语法这很重要。除此之外，我从来没有听过有人说过这个案子。请回答这个问题并兑换我的声誉。
表达式或谓词的顺序是否会对标准SQL中外连接的连接条件产生任何影响？
答案 0 :(得分：5)
不，没有区别。
我个人更喜欢你在Q3中展示的风格，我的一些同事更喜欢Q1中的风格。我不知道有谁会认为他们中的任何一个错误。
查询优化器将查询内部转换为完全不同的内容，因此谓词在完成后不再作为简单比较存在。通常它是在索引或表中查找，因为只能在一个方向上完成，谓词的编写方式没有区别。
我检查了（在SQL Server 2005中）两个查询的执行计划，其中谓词操作数的顺序不同，正如预期的那样，它们是相同的。
答案 1 :(得分：3)
我也更喜欢Q3的JOIN条件顺序：
... ON B.id = A.id -- (Q3)
因为它直接反映出B.id是变化较大的，所以你可以将A.id视为被测试的常数，例如
B.id = 1984
同样，我不想在代码中看到这个...
1984 = B.id
...，和你一样，我不想在查询中看到这个：
A.id = B.id
然而，像生活中的大多数事情一样，有些人喜欢小端，有些人喜欢大端。无论他们根据自己选择的偏好为他们提供什么样的心智模式，他们至少应该能够向你解释他们为什么要这样做的理由A.id = B.id
我认为，我必须改变我的偏好，我的（和你的）首选条件顺序在某些ORM中无效，尤其是Linq。我还没有理解为什么他们强调条件应该是Q1的顺序：
from x in A
join y in B on x.id equals y.id
并且反转条件（与Q3相同，但在SQL查询中它不是错误）顺序导致语法错误，Linq不会接受这一点：
from x in A
join y in B on y.id equals x.id
现在，我必须找到微软Linq设计师更喜欢Q1条件订单的理由。并且如果它有意义的话，试着去欣赏它，并且即使它没有（还）是有意义的，也只是接受它。
关于：
表达式或谓词的顺序是否有所不同 标准SQL中的外连接的连接条件？
结果，否。在性能方面，我还没有看到一个查询，其中连接的条件顺序使查询更快。即使在论坛中，我还没有看到任何人支持扭转条件以使查询更快。
如果他们无法向您解释他们首选条件的顺序的基本原理或心理模型，也许他们只是在做Cargo Cult Programming或更糟，Bikeshedding
答案 2 :(得分：2)
相等比较的顺序对连接的结果没有影响。但它可能由于不可思议的原因影响计算结果的效率。 SQL优化器因为受到这样看似不重要的细节的影响而臭名昭着。
答案 3 :(得分：1)
我更喜欢你的Q1，但是它使在性能上完全没有区别并且对查询优化器完全没有影响。
对我来说，将上一张表放在首位，可以在我的扫描过程中尽快提供相关信息。我可以阅读join table B on A ...并且已经知道哪两个表正在连接在一起。当我阅读join table B on B.blasdjasdid = ...时，我必须扫描得更远，但仍然不知道最重要的信息，哪个表正在加入（这是一种命名空间，列名称将在其下的域名）理解）。另外，如果两个表中的列名称相同（我设计的任何数据库都是惯用的），我可以完全避免扫描，只读join table B on A.SomethingId ...并且已经知道它是= B.SomethingId。
更深入一点，我会鼓励你在workplace.stackexchange.com询问这一事件，因为我怀疑你服务中断的原因与他们告诉你的不符;对此的一些调查可能是富有成效的。我不是说这是你的错，但是给出的理由可能是一个借口。