我觉得这是这是主观的问题之一,并且会变成一个偏好问题,但是:
从可读性的角度来看,我认为只有在必要时才会明确表示。通常,SQL语句非常复杂,不需要阅读大量不必要的文本。
我认为
SELECT TOP 1000 [StoreNumber]
,[Address1]
,[Address2]
,[City]
,[St]
,[Zip]
,[ZipSuffix]
,[LocationType]
,[LocationSubType]
,[Corp]
,[Division]
,[ZoneNumber]
,[DistrictNumber]
,[StateNumber]
FROM [CommonData].[dbo].[vw_StoreData]
是很多比
SELECT TOP 1000 [CommonData].[dbo].[vw_StoreData].[StoreNumber]
,[CommonData].[dbo].[vw_StoreData].[[Address1]
,[CommonData].[dbo].[vw_StoreData].[[Address2]
,[CommonData].[dbo].[vw_StoreData].[[City]
,[CommonData].[dbo].[vw_StoreData].[[St]
,[CommonData].[dbo].[vw_StoreData].[[Zip]
,[CommonData].[dbo].[vw_StoreData].[[ZipSuffix]
,[CommonData].[dbo].[vw_StoreData].[[LocationType]
,[CommonData].[dbo].[vw_StoreData].[[LocationSubType]
,[CommonData].[dbo].[vw_StoreData].[[Corp]
,[CommonData].[dbo].[vw_StoreData].[[Division]
,[CommonData].[dbo].[vw_StoreData].[[ZoneNumber]
,[CommonData].[dbo].[vw_StoreData].[[DistrictNumber]
,[CommonData].[dbo].[vw_StoreData].[[StateNumber]
FROM [CommonData].[dbo].[vw_StoreData]
(当你开始连接表,更糟糕的,如果你要加入跨不同数据库中的表更糟糕的可读性。)
我能看到你可能会说,第二个是更具可读性如果你需要知道哪些数据库,架构和表中的特定字段来自通过查看单独的查询。
但在SQL Server中,例如,你可以在设计器中打开该查询,看看它在一个更加友好的图形视图。
恕我直言,我会用完整的语法的唯一时间是必要时,渡台/数据库/模式的界限时,或者如果你有使用相同的字段名称的两个表。
例子:
SELECT TOP 1000 [CommonData].[dbo].[vw_StoreData].[StoreNumber]
,[Address1]
,[Address2]
,[City]
,[St]
,[Zip]
,[ZipSuffix]
,[LocationType]
,[LocationSubType]
,[Corp]
,[Division]
,[ZoneNumber]
,[DistrictNumber]
,[StateNumber]
FROM [CommonData].[dbo].[vw_StoreData]
Inner Join [CommonData].[dbo].[vw_StorePhones]
ON [CommonData].[dbo].[vw_StorePhones].[StoreNumber] = [CommonData].[dbo].[vw_StoreData].[StoreNumber]
即使在这种情况下,我会使用Table Aliases缩短它,并使其更具可读性。
所有这一切都表示,在现实世界中,这是相当有可能你会发现自己工作的公司,已经决定了标准格式,你需要根据公司的标准进行编码。
我不能不同意这一点。使用表别名肯定有助于减少混乱,并通过单独查看查询来提供必要的提示,以告知哪个表是字段来自哪个表。 +1给你。 – David 2012-04-05 17:15:28