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的列。 没错,你会得到一个错误。 添加一列不需要破坏任何东西。 我从来没有看到写好代码,无错代码,作为一个必要的邪恶。
连接具有相同名称的列的表时需要使用别名。