除非必要(自引用等),否则不使用SQL别名有缺点?
我经常看到如下问题:
SELECT c.name, p.phone, a.number, ct.fbAddress
FROM customer c
INNER JOIN Person p ON p.idCustomer = c.idCuster
INNER JOIN Address a ON .... etc
让我烦恼。它不容易维护。为什么不使用全名?它有问题吗?
这只是一个例子。我用这种快捷方式看到了10-15个表中的查询。它不可读。
编辑:
我应该写“它不易读”而不是“可维护”。如果您只需要在“FROM”子句中更改它,则更容易更改表的名称。
哦,顺便说一句,我看到这些“一个字母的别名”主要来自DBA,所以我可能会遇到一些性能问题。
答案 0 :(得分:6)
不使用别名没有(性能)缺点。但我认为很多人会同意你的偏好。别名使SQL 更多可读。什么更有趣的读给你听?
SELECT c.name, p.phone, a.number, ct.fbAddress
FROM customer c
INNER JOIN Person p
ON p.idCustomer = c.idCuster
INNER JOIN Address a
ON .... etc
或
SELECT customer.name, Person.phone, Address.number, SomeOtherTable.fbAddress
FROM customer
INNER JOIN Person
ON Person.idCustomer = customer.idCuster
INNER JOIN Address
ON .... etc
我会选择前者11次中的10次。更不用说,节省的时间,你不会出现错误,而不必多次输入没有别名的字符使它相当也值得。
我会把它交给你,一个字母别名(即a
,c
,p
)可能很粗糙。但是,如果您有一个名为CompanyBillExtensions
的表格,那么编写/阅读cbe
或BillExt
就更容易,也更直观。
答案 1 :(得分:3)
它有问题吗?
是和否。在您的示例中,没有问题。但是,如果您尝试进行自联接,或通过多个路径连接到同一个表,则需要对表进行别名以使其正常工作。
以下是多次使用同一个表(Address
)时的示例:
SELECT customer.name, home.fbAddress, business.fbAddress
FROM customer
LEFT OUTER JOIN Address home ON home.AddressId = customer.homeAddressId
LEFT OUTER JOIN Address business ON business.AddressId = customer.businessId
答案 2 :(得分:0)
没有任何缺点。我认为使用别名可以提高可读性,如果你正确使用别名,则可以使用别名。如果您在访问10-15个表时经常使用一个字符的别名,那么这是一个命名问题,而不是使用别名的问题。可维护性在于,如果重命名或移动表,则实际上只需要更改链接到别名的位置,而不是在查询中对其进行每次引用。
答案 3 :(得分:0)
他们是否“更好”是一个有争议的主观问题。有些人喜欢你展示的短别名,有些人则不喜欢。有些人对此感到非常强烈。
在实践中,我怀疑它对查询的执行没有任何影响,只要有一个长或短的变量名在编译语言中有所不同(但对编码器来说可能非常重要)。
答案 4 :(得分:0)
上面所有其他重要评论的另一个...使用别名和构建动态查询就像更改FROM表源一样简单,那么您不必担心其他地方的列名或其他连接。 ..例如:
select o.*, od.*
from CurrentOrders o
join CurrentOrdersDetails od
on o.orderid = od.orderid
现在,去一些其他服务器上的档案???
select o.*, od.*
from BackupServer.ArchiveOrders o
join BackupServer.ArchiveOrdersDetails od
on o.orderid = od.orderid
答案 5 :(得分:0)
它不易维护。为什么不使用全名?
易于维护是主观的。假设customer
和person
是基表,并且由于某种原因将来需要相同的查询来分别基于customer
和person
而不是基表来定位视图据为己有。如果您的家庭风格是使用与表名相同的相关名(尽可能),那么您可能必须在同一查询中更改多个名称。但是,如果首选样式是使用与表名称不同的相关名称,则可能只有一个名称需要更改。
当然,如果家庭风格只针对视图而不是基础表,则可能是上述未来的更改可能只涉及对视图定义的更改,使得消耗这些视图的查询保持不变,这可以说是很容易维护,但这完全是另一个考虑因素;)