我很想知道人们是如何使用表别名的。我工作的其他开发人员总是使用表别名，并且总是使用 a、b、c 等的别名。
这是一个例子：
SELECT a.TripNum, b.SegmentNum, b.StopNum, b.ArrivalTime
FROM Trip a, Segment b
WHERE a.TripNum = b.TripNum
我不同意他们的观点，并认为应该更谨慎地使用表别名。
我认为应该在查询中包含两次相同的表时使用它们，或者当表名很长并且在查询中使用较短的名称将使查询更易于阅读时。
我还认为别名应该是一个描述性的名称，而不仅仅是一个字母。在上面的例子中，如果我觉得我需要使用 1 个字母的表别名，我会使用 t 表示 Trip 表，使用 s 表示段表。
使用表别名有两个原因。
首先是化妆品。这些语句更容易编写，并且在使用表别名时可能也更容易阅读。
第二个更实质。如果一个表在 FROM 子句中出现多次，则需要表别名以保持它们的区别。自联接在表包含引用同一表的主键的外键的情况下很常见。
两个示例：一个员工表，其中包含一个引用主管的员工 ID 的主管 ID 列。
二是零件爆炸。通常，这是在具有三列的单独表中实现的：ComponentPartID、AssemblyPartID 和 Quantity。在这种情况下，不会有任何自连接，但在此表和对 Parts 表的两个不同引用之间通常会有一个三向连接。
养成一个好习惯。
我用它们来节省打字。但是，我总是使用类似于函数的字母。所以，在你的例子中，我会输入：
SELECT t.TripNum, s.SegmentNum, s.StopNum, s.ArrivalTime
FROM Trip t, Segment s
WHERE t.TripNum = s.TripNum
对我来说，这只是让阅读更容易。
作为一般规则，我总是使用它们，因为我的存储过程中通常有多个连接。在使用 CodeSmith 等代码生成工具时，它还可以更轻松地自动为您生成别名。
我尽量远离像 a & b 这样的单个字母，因为我可能有多个以字母 a 或 b 开头的表。我采用更长的方法，将引用的外键与别名表连接起来，例如 CustomerContact ...这将是加入 Contact 表时 Customer 表的别名。
我不介意更长的名称的另一个原因是由于我的大部分存储过程都是通过代码 CodeSmith 生成的。我不介意手工输入我可能必须自己构建的少数几个。
使用当前示例，我会执行以下操作：
SELECT TripNum, TripSegment.SegmentNum, TripSegment.StopNum, TripSegment.ArrivalTime
FROM Trip, Segment TripSegment
WHERE TripNum = TripSegment.TripNum
我可以加入已经有几年历史的辩论吗？
还有一个没有人提到的原因。某些数据库中的 SQL 解析器使用别名效果更好。我不记得 Oracle 是否在以后的版本中更改了这一点，但是当涉及到别名时，它会查找数据库中的列并记住它们。当涉及到表名时，即使在语句中已经遇到过，它也会重新检查数据库中的列。因此，使用别名可以加快解析速度，尤其是长 SQL 语句。我相信有人知道这是否仍然是这种情况，其他数据库是否在解析时这样做，如果它改变了，什么时候改变了。
我一直用它，原因：
考虑这个例子：
select col1, col2
from tab1
join tab2 on tab1.col3 = tab2.col3
现在，想象几个月后，您决定将名为“col1”的列添加到 tab2。数据库将默默地允许您这样做，但由于 tab1.col1 和 tab2.col1 之间的歧义，应用程序会在执行上述查询时中断。
但是，我同意你的命名：a、b、c 很好，但在你的例子中t和s会好得多。当我不止一次拥有同一张桌子时，我会使用 t1, t2, ... 或 s1, s2, s3...
在简单查询中，我不使用别名。在包含多个表的查询中，我总是使用它们，因为：
所以而不是例如：
SELECT SUM(a.VALUE)
FROM Domesticvalues a, Foreignvalues b
WHERE a.Value>b.Value
AND a.Something ...
我写的：
select SUM(DVAL.Value)
from DomesticValues DVAL, ForeignValues FVAL
where DVAL.Value > FVAL.Value
and DVAL.Something ...
我发现它只不过是一种偏好。如上所述，别名可以节省输入，尤其是对于长表/视图名称。
使用全名会更难阅读，特别是对于较大的查询或 Order/Product/OrderProduct 场景0
我会使用 t 和 s。或 o/p/op
如果您使用 SCHEMABINDING 那么列必须是合格的
如果将列添加到基表，则限定会减少查询中重复的机会（例如“评论”列）
由于这种限定，总是使用别名是有意义的。
使用 a 和 b 是盲目服从一个奇怪的标准。
我学到的一件事是，尤其是对于复杂的查询；如果您使用别名作为每个字段引用的限定符，则六个月后排除故障要简单得多。然后，您不会试图记住该字段来自哪个表。
我们往往有一些可笑的长表名，所以如果表有别名，我发现更容易阅读。当然，如果您使用派生表或自联接，则必须这样做，因此养成习惯是个好主意。我发现我们的大多数开发人员最终在他们的所有 sps 中为每个表使用相同的别名，所以大多数时候任何阅读它的人都会立即知道 pug 或 mmh 的别名是什么。
我觉得你应该尽可能多地使用它们，但我同意 t & s 比 a & b 更能代表实体。
和其他一切一样，这归结为偏好。当每个开发人员以相同的方式使用别名时，我喜欢你可以依赖于遵循相同约定的存储过程。
去说服你的同事和你在同一个页面上，否则这一切都一文不值。另一种方法是您可以将 Zebra 表作为第一个表并将其别名为 a。那会很可爱。
我只在需要区分字段来自哪个表时才使用它们
select PartNumber, I.InventoryTypeId, InventoryTypeDescription
from dbo.Inventory I
inner join dbo.InventoryType IT on IT.InventoryTypeId = I.InventoryTypeId
在上面的示例中，两个表都有一个 InventoryTypeId 字段，但其他字段名称是唯一的。
始终使用表的缩写作为名称，以便代码更有意义 - 询问您的其他开发人员是否将他们的局部变量命名为 A、B、C 等！
唯一的例外是在 SQL 语法需要表别名但未引用它的极少数情况下，例如
select *
from (
select field1, field2, sum(field3) as total
from someothertable
) X
在上面，SQL 语法需要子选择的表别名，但它没有在任何地方引用，所以我变得懒惰并使用 X 或类似的东西。
我总是使用它们。我以前只在只涉及一个表的查询中使用它们，但后来我意识到 a) 只涉及一个表的查询很少见，b) 只涉及一个表的查询很少会长时间保持这种状态。所以我总是从一开始就把它们放进去，这样我（或其他人）就不必在以后重新安装它们。哦，顺便说一句：根据 SQL-92 标准，我称它们为“相关名称”:)
表别名应该是四件事：
例如，如果您有名为 service_request、service_provider、user 和affiliate（以及许多其他）的表，一个好的做法是将这些表别名为“sr”、“sp”、“u”和“a”，然后这样做在每个可能的查询中。如果这些别名通常与您的组织使用的首字母缩写词一致，这将特别方便。因此，如果“SR”和“SP”分别是服务请求和服务提供者的公认术语，那么上面的别名带有双重有效负载，直观地代表表和它所代表的业务对象。
这个系统的明显缺陷首先是对于包含很多“单词”的表名可能会很尴尬，例如 a_long_multi_word_table_name 会别名为 almwtn 或其他东西，并且很可能你最终会得到这样命名的表，它们的缩写相同. 第一个缺陷可以随心所欲地处理，例如取最后 3 或 4 个字母，或者您认为最有代表性、最独特或最容易键入的任何子集。我在实践中发现的第二个并不像看起来那么麻烦，也许只是运气好。您还可以执行诸如取表中“单词”的第二个字母之类的操作，例如将 account_transaction 别名为“atr”而不是“at”以避免与 account_type 冲突。
当然，无论您是否使用上述方法，别名都应该很短，因为您会非常频繁地键入它们，并且应该始终使用它们，因为一旦您针对单个表编写查询并省略了别名，它就是不可避免的是，您稍后需要在第二个表中编辑具有重复列名的表。
因为我总是完全限定我的表，所以当涉及 JOINed 表时，我使用别名为正在选择的字段提供更短的名称。我认为这使我的代码更容易理解。
如果查询只处理一个源——没有 JOIN——那么我不使用别名。
只是个人喜好问题。
上面的帖子中有很多关于何时以及为什么给表名取别名的好主意。其他人没有提到的是，它还有助于帮助维护人员理解表的范围。在我们公司，我们不允许创建视图。（感谢 DBA。）因此，我们的一些查询变得很大，甚至超过了 Crystal Reports 中 SQL 命令的 50,000 个字符的限制。当一个查询将其表别名为 a、b、c 并且其子查询执行相同的操作，并且其中的多个子查询每个都使用相同的别名时，很容易错误地读取查询的哪个级别。当足够的时间过去时，这甚至会使原始开发人员感到困惑。在查询的每个级别中使用唯一别名可以更容易阅读，因为范围保持清晰。
总是。让它成为一种习惯。