我很想知道人们如何使用表别名。我工作的其他开发人员总是使用表别名,并且总是使用a,b,c等的别名。
以下是一个例子:
SELECT a.TripNum, b.SegmentNum, b.StopNum, b.ArrivalTime
FROM Trip a, Segment b
WHERE a.TripNum = b.TripNum
我不赞同他们,并认为表别名应该更加谨慎使用。
我认为在查询中包含相同的表两次时,或者当表名非常长并且在查询中使用较短的名称时,应该使用它们,这将使查询更容易阅读。
我还认为别名应该是一个描述性名称,而不仅仅是一个字母。在上面的例子中,如果我觉得我需要使用1个字母的表别名,我会使用t表示Trip表,而s表示段表。
答案 0 :(得分:19)
我用它们来节省打字。但是,我总是使用类似于函数的字母。所以,在你的例子中,我会输入:
SELECT t.TripNum, s.SegmentNum, s.StopNum, s.ArrivalTime
FROM Trip t, Segment s
WHERE t.TripNum = s.TripNum
这对我来说更容易阅读。
答案 1 :(得分:19)
使用表别名有两个原因。
首先是化妆品。这些语句更容易编写,并且在使用表别名时也可能更容易阅读。
第二个更具实质性。如果表在FROM子句中出现多次,则需要表别名以使它们保持不同。在表包含引用同一表的主键的外键的情况下,自联接很常见。
两个示例:一个employees表,其中包含一个引用supervisor的employeeID的supervisorID列。
第二个是零件爆炸。通常,这是在一个包含三列的单独表中实现的:ComponentPartID,AssemblyPartID和Quantity。在这种情况下,不会有任何自连接,但是这个表和两个不同的部件表引用之间通常会有一个三向连接。
这是一个很好的习惯。
答案 2 :(得分:6)
作为一般规则我总是使用它们,因为我的存储过程中通常会有多个连接。使用CodeSmith等代码生成工具让它自动为您生成别名时,它也变得更加容易。
我试图远离像& amp; b,因为我可能有多个以字母a或b开头的表格。我使用更长的方法,引用外键与别名表的串联,例如CustomerContact ...这将是加入Contact表时Customer表的别名。
我不介意更长名称的另一个原因是由于我的大多数存储过程都是通过代码CodeSmith生成的。我不介意用手键入少数,我可能需要自己构建。
使用当前的例子,我会做类似的事情:
SELECT TripNum, TripSegment.SegmentNum, TripSegment.StopNum, TripSegment.ArrivalTime
FROM Trip, Segment TripSegment
WHERE TripNum = TripSegment.TripNum
答案 3 :(得分:3)
我可以加入已有几年历史的辩论吗?
没有人提到另一个原因。某些数据库中的SQL解析器可以更好地使用别名。我不记得Oracle是否在以后的版本中对此进行了更改,但是当它出现在别名中时,它会查找数据库中的列并记住它们。当它出现在表名中时,即使它已经在语句中遇到过,它也会重新检查数据库中的列。因此,使用别名可以更快地解析,尤其是长SQL语句。我确信有人知道是否仍然如此,如果其他数据库在解析时执行此操作,并且如果更改,则 时更改。
答案 4 :(得分:1)
我总是使用它,原因:
考虑这个例子:
select col1, col2
from tab1
join tab2 on tab1.col3 = tab2.col3
现在,假设几个月后,您决定将名为'col1'的列添加到tab2。数据库将默默地允许您这样做,但由于tab1.col1和tab2.col1之间的歧义,应用程序在执行上述查询时会中断。
但是,我同意你的命名:a,b,c很好,但 t 和 s 在你的例子中要好得多。当我不止一次拥有同一张桌子时,我会使用t1,t2,...或s1,s2,s3 ......
答案 5 :(得分:1)
在简单查询中,我不使用别名。在多个表的查询中,我总是使用它们,因为:
所以不是例如:
SELECT SUM(a.VALUE)
FROM Domesticvalues a, Foreignvalues b
WHERE a.Value>b.Value
AND a.Something ...
我写道:
select SUM(DVAL.Value)
from DomesticValues DVAL, ForeignValues FVAL
where DVAL.Value > FVAL.Value
and DVAL.Something ...
答案 6 :(得分:0)
我觉得你应该尽可能频繁地使用它们,但我同意t& s代表实体优于&湾
这就像其他一切一样,归结为偏好。我喜欢当每个开发人员以相同的方式使用别名时,您可以遵循相同约定的存储过程。
去说服你的同事与你在同一个页面上,否则这一切都毫无价值。另一种方法是你可以将一个表Zebra作为第一个表,并将它作为一个别名。那会很可爱。
答案 7 :(得分:0)
我只在必要时才使用它们来区分字段来自哪个表
select PartNumber, I.InventoryTypeId, InventoryTypeDescription
from dbo.Inventory I
inner join dbo.InventoryType IT on IT.InventoryTypeId = I.InventoryTypeId
在上面的示例中,两个表都有一个InventoryTypeId字段,但其他字段名称是唯一的。
始终使用表格的缩写作为名称,以便代码更有意义 - 询问您的其他开发人员是否将其局部变量命名为A,B,C等!
唯一的例外是在极少数情况下SQL语法需要表别名但未引用它,例如
select *
from (
select field1, field2, sum(field3) as total
from someothertable
) X
在上面,SQL语法需要subselect的表别名,但它没有在任何地方引用,所以我变得懒惰并使用X或类似的东西。
答案 8 :(得分:0)
我发现它只不过是一种偏好。如上所述,别名可以节省输入,特别是对于长表/视图名称。
答案 9 :(得分:0)
使用全名会使其难以阅读,尤其是对于较大的查询或订单/产品/订单产品scenari0
我会用t和s。或者o / p / op
如果您使用SCHEMABINDING,则无论如何都必须对列进行限定
如果向基表添加列,则限定可降低查询中重复的可能性(例如“注释”列)
由于这种限定,总是使用别名是有意义的。
使用a和b是盲目服从一个奇怪的标准。
答案 10 :(得分:0)
我学到的一件事是特别是对于复杂的查询;如果将别名用作每个字段引用的限定符,则在六个月后进行故障排除要简单得多。那你就不想记住那个字段来自哪个表。
我们往往会有一些可笑的长表名,所以如果表有别名,我会发现它更容易阅读。当然,如果你使用派生表或自我加入,你必须这样做,所以养成这个习惯是个好主意。我发现我们的大多数开发人员最终都会在所有sps中为每个表使用相同的别名,因此大多数人在阅读它时会立即知道什么是哈巴是别名或mmh。
答案 11 :(得分:0)
我总是使用它们。我以前只在涉及一个表的查询中使用它们但后来我意识到a)只涉及一个表的查询很少见,而b)只涉及一个表的查询很少长时间保持这种状态。所以我总是从一开始就把它们放进去,这样我(或其他人)以后就不必再适合它们了。哦和BTW:我称它们为“相关名称”,根据SQL-92标准:)
答案 12 :(得分:0)
表别名应该是四件事:
例如,如果您有名为service_request,service_provider,user和affiliate(以及许多其他表)的表,那么将这些表别名为“sr”,“sp”,“u”和“a”,并在每个查询中执行此操作。如果通常情况下这些别名与您组织使用的首字母缩略词一致,则这是特别方便的。因此,如果“SR”和“SP”分别是服务请求和服务提供者的可接受术语,则上面的别名会为表和它所代表的业务对象提供直观的双重有效负载。
这个系统的明显缺陷首先是对于具有大量“单词”的表名称来说可能很尴尬。 a_long_multi_word_table_name,它将别名为almwtn或其他东西,并且您可能最终会得到名称相同的表格。第一个缺陷可以随意处理,例如取最后3或4个字母,或者您觉得最具代表性,最独特或最容易打字的子集。我在实践中发现的第二个并不像看起来那么麻烦,也许只是运气。你也可以做一些事情,比如在表格中输入“单词”的第二个字母,例如将account_transaction别名化为“atr”而不是“at”,以避免与account_type冲突。
当然你是否使用上述方法,别名应该很短,因为你会经常输入它们,并且应该总是使用它们,因为一旦你对一个表写了一个查询并省略了别名,以后您不可避免地需要在具有重复列名的第二个表中进行编辑。
答案 13 :(得分:0)
上面的帖子中有很多关于何时以及为什么使用别名表名称的好主意。没有人提到的是它在帮助维护者理解表的范围方面也是有益的。在我们公司,我们不允许创建视图。 (感谢DBA。)因此,我们的一些查询变得很大,甚至超过了Crystal Reports中SQL命令的50,000个字符限制。当查询将其表别名为a,b,c,并且其子查询相同时,并且该子查询中的多个子查询各自使用相同的别名,则很容易误认为正在读取的查询级别。当足够的时间过去时,这甚至会使原始开发人员感到困惑。在查询的每个级别中使用唯一别名使得更容易阅读,因为范围仍然清晰。
答案 14 :(得分:0)
因为我总是完全限定我的表,所以当涉及到JOINed表时,我使用别名为要选择的字段提供一个较短的名称。我认为这使我的代码更易于遵循。
如果查询仅处理一个来源-没有JOIN,则我不使用别名。
只是个人喜好问题。
答案 15 :(得分:-1)
始终。养成习惯。