在处理高度规范化的模式时,表别名是一种必要的错误。例如,我不是这个数据库的架构师,所以请放心,为了得到一份干净完整的记录,可能需要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

…等

嗯,有些情况是你 必须 使用它们,就像需要在一个查询中两次联接到同一个表一样。

它还取决于表中是否有唯一的列名。在我们的传统数据库中,所有列都有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中的别名不遵循这个惯例,这让我很苦恼。因此,我必须在整个代码中搜索单个别名,以找出它在哪里(令人沮丧的是,在找到别名声明之前,我必须通读逻辑)。如果不是因为这个,我真的可能更喜欢这个系统。

如果我编写了一个必须由其他人处理的存储过程,我将把别名定义放在文件开头的注释块中作为引用。我真的不明白没有它你们怎么会疯。

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

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

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

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

好

正如前面多次提到的,前缀是一个很好的做法 全部的 列名可以轻松查看哪个列属于哪个表,别名比完整的表名短,因此查询更容易读取,从而更容易理解。当然,如果你使用一个好的混叠方案。

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

如果我自己编写一个查询(通过在编辑器中键入而不是使用设计器),我总是使用别名作为表名,这样我只需要键入一次完整的表名。

我想唯一真正反对他们的是过度抽象。如果您对别名的含义有一个很好的了解(好的命名很有帮助,“a”、“b”、“c”可能会有很大的问题,特别是在您数月或数年后阅读语句时),我认为别名没有什么错。

如其他人所说,加入 要求 如果您多次使用同一个表(或视图),但即使在这种情况之外,别名也可以用来澄清数据源在特定上下文中的用途。以别名的名义,尝试回答 为什么? 您正在访问特定的数据,而不是 什么 数据是。

我爱别名!!!!!我做了一些测试,使用它们与不使用它们,并看到了一些处理增益。我的猜测是,当您处理更大的数据集和复杂的嵌套查询时,处理的收益会比不处理更高。如果我能测试这个,我会告诉你的。

如果要将表与其自身联接,或者在子查询中再次使用列,则需要它们…

如果您认为我的组织具有如下表名,别名就非常好: schemaname.datapointname_subpoint_sub-subpoint_sub-subpoint子点… 我的团队使用了一组相当标准的缩写,所以猜测被最小化了。我们将把programInformationDataPoint简称为pidp,并提交给Sub。

好的是,一旦你以这种方式进行,人们同意它,它使那些hayuge文件变得更小,更容易管理。至少对我来说,传达相同信息的角色越少,我的大脑就越容易接受。

我喜欢长的显式表名(通常超过100个字符),因为我使用许多表,如果这些表名不是显式的,我可能会对每个表存储的内容感到困惑。

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

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

imho,对于有意义的短表名来说并不重要,我有时在数据库中工作,其中表名可以是vwrecoverly或其他一些真正代表用户的随机字符串(由公司策略指定),因此在这种情况下,我发现别名确实有助于使代码更具可读性。(users.username比vwrecoverly.username更敏感)

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

选择 人姓名 从
个人身份

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

它节省了打字时间,而且仍然有一些意义。

较短的名字也让我更容易阅读。

如果您不使用别名,这是您的代码中的一个bug,只是在等待发生。

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

当你做一些小事情,比如在表B中添加一个名为description的列时会发生什么。没错,你会得到一个错误。添加列不需要破坏任何内容。我从来没有看到编写好的代码,没有错误的代码,这是一种必要的邪恶。

在将表与具有相同名称的列联接时,需要使用别名。