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」混淆

回答

相關問題