C'è qualche differenza tra mettere un alias di colonna all'inizio o alla fine della definizione di colonna?


12

Ho sempre visto e scritto i miei alias di colonna come

SELECT 1 as ColumnName

ma oggi ci siamo imbattuti in una query che ha utilizzato

SELECT ColumnName = 1

C'è qualche differenza nel modo in cui vengono eseguite queste due query? O esiste uno standard tra i DBA su quale utilizzare?

Personalmente penso che il secondo sarebbe più facile da leggere / mantenere per le definizioni di colonne più lunghe (buon esempio qui da questo articolo ), tuttavia non ho mai visto la seconda sintassi utilizzata prima di oggi, quindi mi chiedo se c'è qualche motivo che non dovrei essere usandolo.


2
Si noti che la forma di assegnazione dell'aliasing dei commenti non è portatile, quindi sebbene renda le cose abbastanza leggibili quando si fa MOLTO lavoro su colonne derivate, può essere fastidioso doverlo convertire successivamente in un altro DBMS.
Cade Roux,

@Cade Celko fa sempre questo argomento su certe cose. Se devo convertire una base di codice di SQL Server in Oracle o PG o MySQL, la composizione alias sarà l'ultima delle mie preoccupazioni. Dal momento che, a differenza di Celko, non ho alcun interesse ad evitare tutte le funzionalità proprietarie nel caso in cui dovessimo spostare la nostra intera architettura su un RDBMS diverso. Mi chiedo quanto spesso ciò avvenga al di fuori di un'aula ...
Aaron Bertrand

@AaronBertrand Sono d'accordo sulla conversione di massa. Ho convertito un sacco di cose in Teradata e questo è l'ultimo dei problemi. Quello che continua a succedermi più spesso è che importerò interi dati di tabella non elaborati nel mio SQL Server e creerò visualizzazioni o query su di esso o qualsiasi cosa faccia per analizzarli, quindi scriverò una query o proc per l'origine dialetto di sistema da chiamare da SSIS o qualsiasi altra cosa per ottenere SOLO esattamente i dati che voglio attraverso il cavo. In questi casi, scrivo consapevolmente SQL in stile ANSI molto generico. E poi devo ancora cambiare le cose come le funzioni di data.
Cade Roux,

Risposte:


17

Non vi è alcuna differenza nella funzionalità sottostante dei due tipi di aliasing ( asal contrario di =). Ciò che si riduce è esattamente ciò che hai menzionato: leggibilità e manutenibilità.

Secondo me il primo ( <Expression> as <Alias>) è molto più leggibile in quanto si spiega da sé. Quando hai, SELECT ColumnName = 1penso che sarebbe abbastanza facile confonderlo come impostare una variabile in quelle notti lunghe e stanche. Potresti confondere che come SELECT @ColumnName = 1e che sarebbe funzionalità completamente diversa. Pertanto, per eludere qualsiasi possibilità della query "double look", o peggio ancora ... errore nella comprensione / codifica, vado con il SELECT 1 as ColumnName100% delle volte.

La preferenza personale, ma la coerenza (per te e nella tua squadra) è il re . Qualunque cosa tu trovi più semplice, vai e fallo sempre. Non c'è niente di più frustrante che passare avanti e indietro per la risoluzione dei problemi / revisione / manutenzione del codice.

Il terzo modo non menzionato è di usare <Expression> <Alias>. In altre parole, il tuo secondo modo senza la asparola chiave. Penso che questo sia tanto grave quanto il =simbolo. Manca di leggibilità al guadagno di cosa? Non digitare tre caratteri extra ( ase uno spazio). Non ne vale la pena.

A fini esagerati, dai un'occhiata a una query come questa:

use AdventureWorks2012;
go

select
    [New Name] = Name,
    NewDepId = DepartmentID,
    GroupName as GName,
    ModifiedDate MyModDate
from HumanResources.Department;

Non codice che vorrei rivedere.


5
mi dà sempre fastidio vedere l'ultimo, dove escludono la parola chiave "as". Non è necessario ma è difficile leggere quando si guarda un mucchio di codice.

10

Personalmente trovo alias = expressionpiù facile da leggere e comprendere. Il motivo è che quando sto risolvendo SELECTun'affermazione che contiene espressioni lunghe, probabilmente voglio trovare l'espressione tramite il nome della colonna, non viceversa. Rapido, trova l'espressione che l'applicazione vede come alias2:

SELECT
  alias1 = (long expression with aggregates and multiple column references),
  (long expression with aggregates and multiple column references AS alias2
FROM ...

Questa è la mia preferenza. Il tuo potrebbe essere diverso. Non vi è alcun vero vantaggio nell'usare l'uno o l'altro se non per ragioni soggettive / di gusto. L'importante è che tu scelga un modo per farlo e lo fai in modo coerente (e se non lanci una moneta, puoi difendere la tua scelta quando ti imbatti in qualcuno a cui piace l'altro modo). Ma se scrivi un codice per un DBA pignolo come me, preparati a riscriverlo. :-)

Ho blog su questo .

Una cosa di cui mi sento ancora più forte è l'uso di virgolette singole attorno ai nomi di alias, ad es

column AS 'alias'
'alias' = column

Una forma è obsoleta ma entrambe sono molto difficili da leggere - e molti neofiti confondono l'alias come letterale stringa, poiché è quello che sembra. Per gli stessi motivi, detesto assolutamente l'uso delle doppie virgolette ( "alias"). Se hai bisogno di sfuggire al tuo alias perché è una parola riservata o è scelta o formattata in modo errato, usa [square brackets].


2
Completamente d'accordo sull'aspetto delle citazioni. Per quanto riguarda l'espressione lunga, ciò che faccio personalmente è utilizzare i ritorni a capo e la tabulazione della nuova riga e quindi inserire as <Alias>l'ultima riga della definizione della colonna. Ma sicuramente d'accordo, è personale come ti piace il tuo caffè.
Thomas Stringer,

@ThomasStringer vedo che preferirei che il carrello restituisca l'espressione. Se una riga inizia con AS Aliasquesto ASnon è molto utile quando sto scansionando verticalmente per un nome di tabella particolare. Scommetto che non saremmo d'accordo su dove mettere anche le virgole. :-)
Aaron Bertrand

Ho provato a usare virgolette singole attorno ai miei alias di colonna una volta perché li rendeva rossi che si distinguevano in SSMS, ma i fastidi di digitare la chiave di virgoletta così rapidamente sono diventati troppo per me e sono ricaduto sui miei modi pigri. Inoltre, non ha funzionato altrettanto bene per gli scopi previsti quando avevo delle stringhe nella mia query. Probabilmente mi atterrò ASpoiché è quello che usiamo in questo momento (di solito aggiungo una nuova riga prima in AS ColumnNamemodo che si allineino approssimativamente), ma sono d'accordo che =è molto più leggibile nelle definizioni di colonna più lunghe.
Rachel,

2
@AaronBertrand Il mio argomento per mettere al primo posto le virgole è che rende più facile dire dove inizia una definizione di colonna, in particolare con le definizioni di colonne su più righe.
Rachel,

1
@AaronBertrand Di solito non lavoro con un codice con rientro sensibile>. <
Rachel,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.