sql - SQL 表别名 - 好还是坏？

Question

在 SQL 中使用表别名的优缺点是什么？我个人尽量避免使用它们，因为我认为它们会降低代码的可读性（尤其是在阅读大型 where/and 语句时），但我很想听听对此的任何反驳。什么时候使用表别名通常是个好主意，你有什么首选的格式吗？

Answer 1

在处理高度规范化的模式时，表别名是必不可少的。例如，我不是这个数据库的架构师，所以请多多包涵，它可能需要 7 次连接才能得到一个干净完整的记录，其中包括一个人的姓名、地址、电话号码和公司隶属关系。

我倾向于使用短词别名，而不是标准的单字符别名，所以上面示例的 SQL 最终看起来像：

select person.FirstName
      ,person.LastName
      ,addr.StreetAddress
      ,addr.City
      ,addr.State
      ,addr.Zip
      ,phone.PhoneNumber
      ,company.CompanyName
from tblPeople person
left outer join tblAffiliations affl on affl.personID = person.personID
left outer join tblCompany company on company.companyID = affl.companyID

... ETC

Answer 2

好吧，在某些情况下您必须使用它们，例如当您需要在一个查询中两次连接到同一个表时。

它还取决于您是否在表中具有唯一的列名。在我们的旧数据库中，所有列都有 3 个字母的前缀，源自表中的缩写形式，仅仅是因为我们曾经兼容的一个古老的数据库系统并不能很好地支持表别名。

如果您的列名出现在多个表中，则必须将表名指定为列引用的一部分，因此表别名将允许使用更短的语法。

Answer 3

我是这里唯一真正讨厌他们的人吗？

通常，除非必须，否则我不会使用它们。我真的很讨厌不得不阅读类似的东西

select a.id, a.region, a.firstname, a.blah, b.yadda, b.huminahumina, c.crap
from table toys as a
inner join prices as b on a.blah = b.yadda
inner join customers as c on c.crap = something else
etc

当我阅读 SQL 时，我想确切地知道我在阅读时选择了什么；别名实际上让我更加困惑，因为在我真正得到表名之前，我必须通过列的行，这通常表示有关别名没有的数据的信息。如果你做了别名也许没关系，但我经常阅读 StackOverflow 上的问题，其中的代码似乎无缘无故地使用别名。（此外，有时，有人会在语句中创建别名但不使用它。为什么？）

我认为表格别名被使用得如此之多，因为很多人不喜欢打字。不过，我不认为这是一个很好的借口。这个借口是我们最终得到糟糕的变量命名、糟糕的函数首字母缩写词、糟糕的代码的原因......我会花时间输入全名。不过，我是一个快速打字员，所以也许这与它有关。（也许将来，当我有腕管时，我会重新考虑我对别名的看法。：P）我特别讨厌在 PHP 代码中运行表别名，我相信绝对没有理由必须这样做 -你只需要输入一次！

我总是在我的语句中使用列限定符，但我不反对输入很多，所以我很乐意多次输入全名。（当然，我确实滥用了 MySQL 的制表符补全。）除非这是我必须使用别名的情况（如其他答案中描述的一些），否则我发现额外的抽象层很麻烦且不必要。

编辑：（一年多后）我正在处理一些使用别名的存储过程（我没有写它们，我是这个项目的新手），它们有点痛苦。我意识到我不喜欢别名的原因是因为它们是如何定义的。您知道在作用域的顶部声明变量通常是一种很好的做法吗？（通常在一行的开头？） SQL 中的别名不遵循这个约定，这让我咬牙切齿。因此，我必须在整个代码中搜索单个别名以找出它的位置（令人沮丧的是，我必须在找到别名声明之前通读逻辑）。如果不是这样，老实说，我可能会更喜欢这个系统。

如果我曾经编写过其他人必须处理的存储过程，我会将别名定义放在文件开头的注释块中，作为参考。老实说，我无法理解没有它你们怎么不会发疯。

Answer 4

好的

正如之前多次提到的那样，为所有列名添加前缀以轻松查看哪个列属于哪个表是一个好习惯 - 别名比完整的表名短，因此查询更易于阅读和理解。当然，如果您使用良好的别名方案。

如果您创建或阅读应用程序的代码，该应用程序使用外部存储或动态生成的表名，那么如果没有别名，乍一看真的很难分辨出所有这些“%s”或其他占位符代表什么。这不是极端情况，例如许多 Web 应用程序允许在安装时自定义表名前缀。

Answer 5

Microsoft SQL 的查询优化器受益于使用完全限定名称或别名。

我个人更喜欢别名，除非我有很多表，否则它们往往是单字母的。

--seems pretty readable to me ;-)
select a.Text
from Question q
    inner join Answer a
        on a.QuestionId = q.QuestionId

Sql 字符串的执行时间也有实际限制——别名使这个限制更容易避免。

Answer 6

如果我自己编写查询（通过在编辑器中输入而不是使用设计器），我总是为表名使用别名，这样我只需要输入一次完整的表名。

我真的很讨厌阅读由设计人员生成的查询，其中完整的表名作为每个列名的前缀。

Answer 7

我想唯一真正反对他们的是过度抽象。如果您对别名所指的内容有一个很好的了解（良好的命名会有所帮助；“a”、“b”、“c”可能会产生很大的问题，尤其是当您在数月或数年后阅读该声明时），我认为没有错有别名。

正如其他人所说，如果您多次使用同一个表（或视图） ，则连接需要它们，但即使在这种情况之外，别名也可以用来阐明数据源在特定上下文中的用途。在别名的名称中，尝试回答您访问特定数据的原因，而不是数据是什么。

Answer 8

我喜欢别名！！！！我已经使用它们与不使用它们进行了一些测试，并且已经看到了一些处理收益。我的猜测是，当您处理更大的数据集和复杂的嵌套查询时，处理增益会比没有处理时更高。如果我能够对此进行测试，我会告诉你的。

Answer 9

如果要将表连接到自身，或者在子查询中再次使用该列，则需要它们...

Answer 10

如果您认为我的组织具有如下表名，则别名非常好：SchemaName.DataPointName_SubPoint_Sub-SubPoint_Sub-Sub-SubPoint... 我的团队使用一组非常标准的缩写，因此可以最大限度地减少猜测。我们会说 ProgramInformationDataPoint 缩短为 pidp，而提交只是 sub。

好消息是，一旦你以这种方式开始并且人们同意它，它会使那些 HAYUGE 文件更小并且更易于管理。至少对我来说，用更少的字符来传达相同的信息似乎对我的大脑来说更容易一些。

Answer 11

恕我直言，有意义的短表名并不重要，我有时在数据库中工作过，其中表名可能是 VWRECOFLY 或其他一些真正代表用户的随机字符串（由公司政策规定），所以在在那种情况下，我发现别名确实有助于使代码更易读。（users.username 比 VWRECOFLY.username 更有意义）

Answer 12

我喜欢长的显式表名（超过 100 个字符并不少见），因为我使用了许多表，如果名称不明确，我可能会对每个表存储的内容感到困惑。

因此，当我编写查询时，我倾向于使用在查询范围内有意义的较短别名，这使代码更具可读性。

Answer 13

我总是在查询中使用别名，它是我公司代码指南的一部分。首先，当连接表中存在具有相同名称的列时，您需要别名或表名。在我看来，别名提高了复杂查询的可读性，让我可以快速查看每列的位置。我们甚至在单表查询中使用别名，因为经验表明单表查询不会长时间保持单表。

Answer 14

我总是使用别名，因为要在 MSSQL 上获得适当的性能，您需要始终使用模式作为前缀。所以你会看到很多

从 dbo.Person 中选择
Person.Name 作为 Person

Answer 15

我在编写查询时总是使用别名。通常我会尝试将表名缩写为 1 或 2 个代表字母。所以用户变成了你，债务人交易变成了dt等等......

它节省了打字时间，但仍然具有一定的意义。

较短的名称也使我更容易阅读。

Answer 16

如果您不使用别名，那么它就是您的代码中的一个错误，它正在等待发生。

SELECT Description -- actually in a
 FROM
 table_a a,
 table_b b
 WHERE
 a.ID = b.ID

当您执行一些小操作时会发生什么，例如向 Table_B 添加一个名为 Description 的列。没错，你会得到一个错误。添加一列不需要破坏任何东西。我从未将编写好的代码、无错误的代码视为必要的邪恶。

Answer 17

连接具有相同名称的列的表时需要别名。