SQL表别名 - 好还是坏?

时间:2008-08-14 13:53:33

标签: sql alias

在SQL中使用表别名有哪些优缺点?我个人试图避免它们,因为我认为它们使代码的可读性降低(特别是在阅读大的where /和语句时),但我有兴趣听到任何反对点。什么时候使用表别名通常是个好主意,你有什么首选格式吗?

17 个答案:

答案 0 :(得分:28)

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

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

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

答案 1 :(得分:28)

在处理高度规范化的模式时,表别名是必要的恶魔。例如,我不是这个数据库的架构师,所以请耐心等待,它可能需要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

...等

答案 2 :(得分:16)

我是唯一真正讨厌他们的人吗?

一般来说,除非必须,否则我不会使用它们。我真的很讨厌读

之类的东西
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中的别名不遵循这个惯例,这让我磨牙。因此,我必须在整个代码中搜索单个别名以找出它的位置(令人沮丧的是,我必须在找到别名声明之前阅读逻辑)。如果不是那样的话,老实说我可能会更喜欢这个系统。

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

答案 3 :(得分:9)

Microsoft SQL的查询优化器可以使用完全限定名称或别名。

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

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

对于执行Sql字符串的时间也存在实际限制 - 别名使这个限制更容易避免。

答案 4 :(得分:9)

正如前面多次提到的那样,最好在所有列名前加上前缀,以便轻松查看哪个列属于哪个表 - 并且别名比完整的表名短,所以查询更容易阅读,从而理解。如果你当然使用一个好的别名方案。

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

答案 5 :(得分:5)

如果我自己编写查询(通过在编辑器中键入而不使用设计器),我总是使用别名作为表名,所以我只需要输入一次完整的表名。 / p>我真的很讨厌读取设计器生成的查询,并使用完整的表名作为每个列名的前缀。

答案 6 :(得分:5)

我认为真正反对他们的唯一事情是过度抽象。如果你会很清楚别名所指的是什么(好的命名有帮助;'a','b','c'可能很成问题,特别是当你几个月或几年后阅读声明时),我认为没有错带别名。

正如其他人所说,如果您多次使用同一个表(或视图),则加入需要,但即使在这种情况之外,别名也可用于阐明数据源的用途一个特定的背景。在别名的名称中,尝试回答为什么您正在访问特定数据,而不是 数据是什么。

答案 7 :(得分:4)

我喜欢别名!!!!我已经完成了一些使用它们的测试,并且已经看到了一些处理收益。我的猜测是,当您处理更大的数据集和复杂的嵌套查询时,处理收益会更高。如果我能测试一下,我会告诉你的。

答案 8 :(得分:3)

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

答案 9 :(得分:2)

如果您认为我的组织的表名如下,则别名很好: SchemaName.DataPointName_SubPoint_Sub-SubPoint_Sub - 子下点...... 我的团队使用了一套非常标准的缩写,因此可以最大限度地减少猜测。我们会说ProgramInformationDataPoint缩写为pidp,并提交给sub。

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

答案 10 :(得分:1)

恕我直言,对于有意义的短表名称并不重要,我有时会在数据库中工作,其中表名可能类似于VWRECOFLY或其他一些真正代表用户的随机字符串(由公司政策决定) ,所以在这种情况下,我发现别名确实有助于使代码FAR更具可读性。 (users.username比VWRECOFLY.username更有意义)

答案 11 :(得分:1)

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

答案 12 :(得分:1)

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

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

答案 13 :(得分:0)

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

它节省了打字并且仍然带有一些含义。

较短的名字也使我的阅读更具可读性。

答案 14 :(得分:0)

如果您不使用别名,那么代码中的错误只是等待发生。

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

当您执行诸如向表_B添加名为Description的列之类的小事情时会发生什么。没错,你会收到错误。添加列不需要破坏任何内容。我从来没有看到编写好的代码,无错误的代码,作为必要的邪恶。

答案 15 :(得分:0)

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

  

选择     Person.Name   从
    dbo.Person As Person

答案 16 :(得分:-1)

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