SQL表别名 – 好还是坏？
在SQL中使用表别名有什么优点和缺点？ 我个人试图避免它们，因为我认为它们使得代码更不可读（特别是在阅读大量的where /语句时），但是我有兴趣听到任何相反的意见。 什么时候使用表别名通常是一个好主意，并且你有什么首选格式？
处理高度规范化的模式时，表别名是必要的恶意。 例如，我不是这个数据库的架构师，所以我可以接受7个连接，以获得一个清晰完整的logging，其中包括一个人的姓名，地址，电话号码和公司隶属关系。
而不是有点标准的单个字符别名，我倾向于赞成短的别名，所以上面的例子的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 …等
那么，有些情况下您必须使用它们，例如当您需要在一个查询中连接两次相同的表时。
这也取决于你有不同的表名列名称。 在我们的遗留数据库中，所有列都有三个字母的前缀，源自表格中的缩写forms，只是因为我们曾经兼容的一个古老的数据库系统并不支持表别名。
如果列名出现在多个表中，那么将表名指定为列引用的一部分是必须的，因此表别名将允许使用较短的语法。
我是唯一真正讨厌他们的人吗？
一般来说，除非必须，否则我不会使用它们。 我真的很讨厌阅读类似的东西
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时，我喜欢在读取时确切地知道我select的是什么; 别名实际上让我更加困惑，因为在实际得到表名之前，我必须通过列的行列，这通常表示别名不包含的数据的信息。 也许没关系，如果你做了别名，但我通常阅读StackOverflow上的问题，似乎没有很好的理由使用别名的代码。 （另外，有时候，有人会在声明中创build一个别名，而不是使用它，为什么？）
我认为桌子别名的使用非常多，因为很多人不喜欢打字。 不过，我认为这不是一个好的借口。 这个借口是我们以可怕的variables命名，可怕的函数首字母缩写，错误的代码结束的原因…我会花时间打出全名。 不过，我是一个快速的typer，所以也许这与它有关。 （也许在将来，当我有腕隧道的时候，我会重新考虑我对别名的看法：P）我特别讨厌在PHP代码中运行表别名，在那里我相信绝对没有理由必须这么做 – 你只需要input一次！
我总是在列表中使用列限定符，但是我不想反复input，所以我很乐意多次input全名。 （当然，我滥用MySQL的tab完成。）除非是我必须使用别名（如其他答案中描述的一些）的情况，否则我会发现额外的抽象层很麻烦并且是不必要的。
编辑:(一年以后）我正在处理一些使用别名的存储过程（我没有写出来，我是新来的这个项目），他们是痛苦的。 我意识到我不喜欢别名的原因是因为它们是如何定义的。 你知道在范围的顶部声明variables是一种很好的做法吗？ （通常在一行的开始？）SQL中的别名不遵循这个约定，这使我磨牙。 因此，我必须search整个代码以find一个单独的别名（以及令人沮丧的是，在查找别名声明之前，我必须通读逻辑）。 如果不是这样的话，我真的可能会更喜欢这个系统。
如果我写过一个其他人将不得不处理的存储过程，我将把别名定义放在文件开头的注释块中作为参考。 我真的不明白，如果没有它，你们不会发疯。
Microsoft SQL的查询优化器可以使用完全限定的名称或别名。
我个人更喜欢别名，除非我有很多表，他们往往是单个字母的。
--seems pretty readable to me ;-) select a.Text from Question q inner join Answer a on a.QuestionId = q.QuestionId
对于一个Sqlstring可以执行多长时间也有实际的限制 – 别名使得这个限制更容易避免。
好
正如前面已经提到过的那样，为所有列名添加前缀是很好的做法，以便轻松查看哪个列属于哪个表 – 并且别名比全表名更短，以便查询更易于理解。 如果你使用一个好的别名scheme当然。
如果您创build或读取使用外部存储的或dynamic生成的表名称的应用程序的代码，则无需使用别名，一眼就可以看出所有这些“％s”或其他占位符代表的是什么。 这不是一个极端的例子，例如许多Web应用程序允许在安装时自定义表名前缀。
如果我自己编写查询（通过在编辑器中input而不使用devise器），我总是使用别名作为表名，所以我只需input一次完整的表名即可。
我真的很讨厌阅读由devise师生成的查询全表名作为每个列名称的前缀。
我想唯一真正对他们说话的是过度的抽象。 如果你能清楚别名的含义是什么（好的命名有帮助;'a'，'b'，'c'可能会有问题，特别是当你在几个月或几年后阅读陈述时），我没有看到任何错误与别名。
正如其他人所说的，如果您多次使用同一个表（或视图），那么连接会要求连接，但即使在这种情况之外，别名也可以用来澄清数据源在特定上下文中的用途。 在别名的名字，试着回答你为什么访问特定的数据，而不是数据是什么 。
我爱别名！ 我已经做了一些testing使用它们，而不是和已经看到一些处理收益。 我的猜测是，当处理较大的数据集和复杂的嵌套查询时，处理收益会更高。 如果我能够testing这个，我会让你知道的。
如果您要将表join到自己的表中，或者如果在子查询中再次使用列，则需要它们…
别名是伟大的，如果你认为我的组织有像这样的表名：SchemaName.DataPointName_SubPoint_Sub-SubPoint_Sub-Sub-SubPoint …我的团队使用一个非常标准的缩写集，所以猜测是最小化。 我们会说ProgramInformationDataPoint缩短到pidp，并提交到只是子。
好事是，一旦你这样做，人们就会认同它，这使得HAYUGE文件变得更小，更容易pipe理。 至less对于我来说，传达相同信息的字符变less了，我的大脑似乎变得容易一些。
我喜欢很长的显式表名（这通常超过100个字符），因为我使用了很多表，如果名字不明确，我可能会对每个表存储的内容感到困惑。
所以当我编写查询时，我倾向于使用在查询范围内有意义的更短的别名，并使代码更具可读性。
我总是在我的查询中使用别名，这是我公司代码指南的一部分。 首先，当连接表中有相同名称的列时，需要别名或表名。 在我看来，别名提高了复杂查询的可读性，并使我能够快速查看每列的位置。 我们甚至使用单表查询的别名，因为经验表明，单表查询不会长时间保持单表。
恕我直言，这与真正有意义的短表名无关，我偶尔会处理数据库，表名可能是VWRECOFLY或其他随机string（由公司策略规定），这些string代表用户，所以在这种情况下，我发现别名确实有助于使代码更可读。 （users.username使得VWRECOFLY.username更加精确）
我总是使用别名，因为要在MSSQL上获得正确的性能，您需要始终以模式作为前缀。 所以你会看到很多
从中selectPerson.Name
作为人的dbo.Person
编写查询时，我总是使用别名。 通常我会尝试缩写表名称为1或2代表字母。 所以用户变成你和debtor_transactions成为dt等…
这节省了打字的时间，还有一些意义。
较短的名称使它对我更具可读性。
如果你没有使用别名，这是你的代码只是等待发生的错误。
SELECT Description -- actually in a FROM table_a a, table_b b WHERE a.ID = b.ID
当你做一些小事情时会发生什么，比如添加一个名为Description到Table_B的列。 没错，你会得到一个错误。 添加一列不需要破坏任何东西。 我从来没有看到写好代码，无错代码，作为一个必要的邪恶。
连接具有相同名称的列的表时需要使用别名。
