T-SQL - 使用“=”与“as”混淆

在使用AS之前有什么特别的原因（性能或其他）使用AS时=混淆列时？T-SQL - 使用“=”与“as”混淆

我个人的偏好（为便于阅读）是用这样的：

select 
alias1  = somecolumn 
alias2  = anothercolumn 
from 
tables 
etc...

，而不是这样的：

select 
somecolumn as alias1 
anothercolumn as alias2 
from 
tables 
etc...

我是不是任何理由我不应该这样做错过了？当涉及格式化他们的列时，其他人的偏好是什么？

来源

2009-10-01 mwjackson

我应该详细说明我的动机。我发现在长查询和嵌套查询中搜索别名列是维护查询最烦人和可能出错的部分。恕我直言其他可能的后果，如区分选择对比=和=在哪里条款和其他可能的后果远远不是对我的麻烦，我想知道别人的意见是什么？ – mwjackson 2009-10-01 11:24:21

你有我的投票...但看起来我们的人数超过 – 2009-10-01 11:26:26

它会出现这样。我认为重要的是它的可读性和很好的理念，无论人们的偏好是什么... – mwjackson 2009-10-01 12:20:21

'='是无效的ANSI SQL，因此如果您希望在不同的DBMS上运行您的应用程序，则会遇到困难。

（当使用ANSI形式，但可选的“AS”被省略，我觉得结果难以阅读，亲自它。）

来源

2009-10-01 11:57:53 bobince

这是一个有效的观点，但我认为95％的情况下可读性的提高超过了5您需要针对不同的DBMS执行查询的情况的百分比 – mwjackson 2009-10-01 12:23:52

可读性判断相当主观！ :-)你需要一个不同的DBMS的频率取决于项目的类型;如果它是一个面向MS公司的内部工具，那么依靠T-SQL扩展可能是合适的;对于一个开源项目来说，它并不适合。 – bobince 2009-10-01 12:37:00

+1这将是我考虑改变我的SQL写作风格的唯一原因，但我会推迟到事件发生（这可能永远不会）。 – 2009-10-01 12:39:09

我更喜欢使用AS，因为在where语句中使用了=，并且在长查询中可能会引起混淆。

来源

2009-10-01 11:14:40 pgb

只有当你在select子句中进行嵌套选择时，或者没有很好地格式化你的查询时，这两者在我看来都是更加关注的问题 – mwjackson 2009-10-01 12:22:12

我使用'='和'AS'以不同的方式格式化查询。经过长时间的SQL Server工作后，我更喜欢使用'='。在我的情况中，因为某些列需要大量逻辑并且能够定位'AS'在某些情况下可能会变得复杂，而'='将始终在ALIAS之后。正如@mwjackson所说，这完全取决于你如何格式化代码，以及就我个人的意见而言。我刚来这个问题只是因为我想确定一个和另一个之间的表现，但可读性仍然是主观的。 – JotaPardo 2017-08-14 21:58:18

我不会使用它，因为它看起来太像平等操作。 'AS'很明确，因为它对我来说并不含糊。

它与sql中不使用大写字母相同，我发现它很难阅读。

来源

2009-10-01 11:15:25

我更喜欢不使用这些。我只是给列的名称没有任何关键字之间

来源

2009-10-01 11:18:52 Scoregraphic

我也是这样做的，因为在查询中使用“as”后面的痛苦个人历史。我*总是*通过使用空格和（当有多个）列对齐时确保这些别名脱颖而出。 – 2009-10-01 13:54:47

**即使我更喜欢使用'as'而不是'='。 '='使代码混淆。

e.g：

column as alias1

来源

2009-10-01 11:22:46 anishMarokey

...这对人类意义重大吗？ ;） – Scoregraphic 2009-10-01 11:28:05

我更喜欢使用'='。在我的情况中，因为某些列需要大量逻辑并且能够定位'AS'在某些情况下可能会变得复杂，而'='将始终在ALIAS之后。这完全取决于你如何格式化代码，以及就我个人的意见而言。我只是因为想确定一方和另一方之间的表现，所以才会提出这个问题，但可读性仍然是主观的。 – JotaPardo 2017-08-14 22:00:58

把一些重，我更喜欢使用=。

如果我是以某种方式查询结果的消费者，我发现查看作为消费者的哪些列可以使用更方便。

我喜欢这个

SELECT 
     [ElementObligationID] = @MaxElementObligationID + eo.ElementObligationID 
     , [ElementID] = eo.ElementID 
     , [IsotopeID] = eo.IsotopeID 
     , [ObligationID] = eo.ObligationID 
     , [ElementWeight] = eo.ElementWeight * -1 
     , [FissileWeight] = eo.FissileWeight * -1 
     , [Items] = eo.Items * -1 
     , [Comment] = eo.Comment 
     , [AdditionalComment] = eo.AdditionalComment 
     , [Aanmaak_userid] = @UserID 
     , [Aanmaak_tijdstip] = GetDate() 
     , [Laatste_wijziging_userid] = @UserID 
     , [Laatste_wijziging_tijdstip] = GetDate() 
FROM dbo.KTM_ElementObligation eo 
     INNER JOIN dbo.KTM_ElementObligationArticle eoa ON 
      eoa.ElementObligationID = eo.ElementObligationID

在这个

SELECT 
     @MaxElementObligationID + eo.ElementObligationID AS [ElementObligationID] 
     , eo.ElementID AS [ElementID] 
     , eo.IsotopeID AS [IsotopeID] 
     , eo.ObligationID AS [ObligationID] 
     , eo.ElementWeight * -1 AS [ElementWeight] 
     , eo.FissileWeight * -1 AS [FissileWeight] 
     , eo.Items * -1 AS [Items] 
     , eo.Comment AS [Comment] 
     , eo.AdditionalComment AS [AdditionalComment] 
     , @UserID AS [Aanmaak_userid] 
     , GetDate() AS [Aanmaak_tijdstip] 
     , @UserID AS [Laatste_wijziging_userid] 
     , GetDate() AS [Laatste_wijziging_tijdstip] 
FROM dbo.KTM_ElementObligation eo 
     INNER JOIN dbo.KTM_ElementObligationArticle eoa ON 
      eoa.ElementObligationID = eo.ElementObligationID

只是我2C。

来源

2009-10-01 11:22:57

+1：我曾在几个使用“别名= ...”和“...作为别名”的项目上混合使用不同的存储过程 - 偶尔也使用相同的存储过程。我发现“别名= ...”更容易阅读和写作。特别是，我发现使用“... {tab} {tab} {tab}作为别名的右对齐别名”稍微更具可读性但没有对齐，但维护是一场噩梦。 – Juliet 2009-10-01 15:02:16

=可以与赋值和相等混淆;实际上，形式我真的不一样的是，当它看起来像一个字符串（通常在空间参与）：

somecolumn as 'alias 1'

或

'alias 1' = somecolumn

我远远更喜欢另类符号：

somecolumn as [alias 1]

来源

2009-10-01 11:28:31

只有当你在select子句中进行嵌套选择，或者没有很好地格式化你的查询时，才会出现混淆的可能性，这两者在我看来都是更为关注的 – mwjackson 2009-10-01 12:26:40

另一种表示法：'[别名1] = somecolum' – JotaPardo 2017-08-14 22:01:54

“=”只是普通的含糊不清。

如果您缩进来分解每个select子句...通过“=”语法声明

select 
    alias1  = somecolumn, 
    alias2  = anothercolumn, 
    result  = column1 * column2 
from 
    table 
.... 


select 
    somecolumn as   alias1, 
    anothercolumn as  alias2, 
    column1 * column2 as result 
from 
    tables 
    ...

来源

2009-10-01 11:36:21 gbn

虽然我不同意=是模棱两可的，这是一个不错的选择... – mwjackson 2009-10-01 12:28:15

良好的缩进确实有助于可读性。但是我总是将别名前面的“AS”对齐。它更具可读性。 – 2009-10-01 18:36:02

列别名弃用SQL Server 2008和在下一版本不支持。见MSDN article。

来源

2009-10-01 11:47:40 devio

只提到了*'string_alias'=表达式*，**不支持** * column_alias =表达式*至少仍然可用 – 2009-10-01 11:58:42

后缀别名形式（带或不带“AS”）是一致的列和表别名。就个人而言，我想一个选项，以强制使用“AS”，然后你不会有这种情况：

select 
    columnA, 
    columnB 
    columnC 
from 
    table

生产两列而不是预期的3

结果集

我也想说，以前缀“=”的形式，它可以使更多的困难，如果你混合获得一个结果集和变量赋值阅读：

select 
    cA = columnA, 
    @cB = columnB, 
    cC = columnC 
from 
    table

来源

2009-10-01 12:12:37

虽然我使用偏好AS，这里真正关键的是制定一个企业标准并遵循它。如果更多的人使用AS而不是=，那么每个人都应该使用它。编码标准是维护代码更容易，而不是您选择的特定标准。如果每个人都使用相同的东西，那么你的眼睛会习惯于挑选它。

来源

2009-10-01 13:39:25 HLGEM

三个方面，我所知道的别名：

TableColumn的AS MyAlias
TableColumn的MyAlias
MyAlias = TableColumn的

回复：1），我喜欢这个，因为它是最自我记录的代码（IMO），它可以让我搜索AS，如果我需要查找别名..

Re：2），这是我的第二选择，但没有AS，我不确定这是否是剪切粘贴错误，特别是在格式不正确的长查询中。

回复：3），我不喜欢这一点，因为A）它看起来像一个任务，和b）它融合了太多与ON条款和CASE声明

所以，我的票是使用AS您的别名的关键字。

来源

2009-10-01 13:47:45 RedFilter

SQL中的'='可交换与别名有关吗？我从来没有见过它用于描述而不是'MyAlias = TableColumn'。 – 2009-10-01 14:23:05

你说得对，我换了它，现在修好了。 – RedFilter 2009-10-01 14:24:15

您不必为使用

降AS和使用

SELECT originalname alias 
FROM 
    tablename

来源

2009-10-01 13:51:02

我喜欢

SELECT 
column1 = table.column1 
,column2 = table.colum2 
FROM table

我找到尽可能不容易noticable相比等号（=）（我可以发现=比AS快）

另外，当只是做SELECT列别名时， s混乱知道哪一个是哪个:)

来源

2009-10-01 14:46:13 jerryhung

我不像其他人那样幸运的发布了这里。我使用的代码通常由其他人编写，并且很少有没有CASE语句或其他计算，连接或逻辑导致单个条目跨越几行T_SQL脚本。

使用等号代替“AS”更容易阅读。用等号表示您正在查找的别名是该行的第一个位置。当使用'AS'并且T_SQL跨越多行时，别名可以在任何地方。

当使用等于“AS”时，找到'Items'别名比使用'AS'要容易得多。

SELECT 
     ElementObligationID = @MaxElementObligationID + eo.ElementObligationID 
     , ElementID = eo.ElementID 
     , IsotopeID = eo.IsotopeID 
     , ObligationID = eo.ObligationID 
     , ElementWeight = eo.ElementWeight * -1 
     , FissileWeight = eo.FissileWeight * -1 
     , Items = CASE WHEN eo.Items < 0 THEN eo.Items * -1 
        WHEN eo.Items > 0 THEN eo.Items 
        ELSE 0 END 
     , Comment = eo.Comment 
     , AdditionalComment = eo.AdditionalComment 
     , Aanmaak_userid = @UserID 
     , Aanmaak_tijdstip = GetDate() 
     , Laatste_wijziging_userid = @UserID 
     , Laatste_wijziging_tijdstip = GetDate() 
FROM dbo.KTM_ElementObligation eo 
     INNER JOIN dbo.KTM_ElementObligationArticle eoa ON 
      eoa.ElementObligationID = eo.ElementObligationID

现在想象一下这里有多于5倍的代码量，需要找到'Items'别名。

SELECT 
     @MaxElementObligationID + eo.ElementObligationID AS ElementObligationID 
     , eo.ElementID AS ElementID 
     , eo.IsotopeID AS IsotopeID 
     , eo.ObligationID AS ObligationID 
     , eo.ElementWeight * -1 AS ElementWeight 
     , eo.FissileWeight * -1 AS FissileWeight 
     , CASE WHEN eo.Items < 0 THEN eo.Items * -1 
      WHEN eo.Items > 0 THEN eo.Items 
      ELSE 0 END AS Items 
     , eo.Comment AS Comment 
     , eo.AdditionalComment AS AdditionalComment 
     , @UserID AS Aanmaak_userid 
     , GetDate() AS Aanmaak_tijdstip 
     , @UserID AS Laatste_wijziging_userid 
     , GetDate() AS Laatste_wijziging_tijdstip 
FROM dbo.KTM_ElementObligation eo 
     INNER JOIN dbo.KTM_ElementObligationArticle eoa ON 
      eoa.ElementObligationID = eo.ElementObligationID

'AS'vs'='不是一个反复无常和任意的偏好。当我说有时需要几分钟才能找到我正在查找的别名时，我并不夸张，因为我现在负责维护的脚本的作者没有使用带有别名的等号。我想不出比付IT专业人员在代码中寻找别名更大的时间，金钱和资源浪费！ 如果您关心可维护性，可读性和效率，那么有正确和错误的答案。你的工作是提供商业价值，而不是花你的一天寻找沃尔多！

来源

2017-12-21 16:10:03 mihalko

T-SQL - 使用“=”与“as”混淆

回答

相关问题