Y a-t-il une différence entre mettre un alias de colonne au début ou à la fin de la définition de colonne?

J'ai toujours vu et écrit mes alias de colonne comme

SELECT 1 as ColumnName

mais aujourd'hui est tombé sur une requête qui a utilisé

SELECT ColumnName = 1

Y a-t-il une différence dans la façon dont ces deux requêtes sont exécutées? Ou existe-t-il une norme parmi les DBA sur laquelle utiliser?

Personnellement, je pense que la 2e serait plus facile à lire / à entretenir pour les définitions de colonnes plus longues (bon exemple ici de cet article ), mais je n'ai jamais vu la 2e syntaxe utilisée avant aujourd'hui, alors je me demande s'il y a une raison pour laquelle je ne devrais pas être En l'utilisant.

Il n'y a aucune différence dans la fonctionnalité sous-jacente des deux types d'alias (par asopposition à =). Cela se résume exactement à ce que vous avez mentionné: lisibilité et maintenabilité.

À mon avis, l'ancien ( <Expression> as <Alias>) est beaucoup plus lisible car il est explicite. Quand vous l'avez, SELECT ColumnName = 1je pense qu'il serait assez facile de confondre cela avec le réglage d'une variable lors de ces longues nuits fatiguées. Vous pourriez confondre cela avec SELECT @ColumnName = 1et ce serait une fonctionnalité complètement différente. Par conséquent, pour contourner toute possibilité de requête "double look", ou pire encore ... erreur de compréhension / codage, je pars avec SELECT 1 as ColumnName100% du temps.

Préférence personnelle, mais la cohérence (pour vous et au sein de votre équipe) est primordiale . Tout ce que vous trouvez le plus facile, allez-y et faites-le tout le temps. Il n'y a rien de plus frustrant que de faire des allers-retours pour le dépannage / la révision / la maintenance du code.

La troisième façon non mentionnée est d'utiliser <Expression> <Alias>. En d'autres termes, votre deuxième moyen sans le asmot clé. Je pense que c'est aussi mauvais que le =symbole. Il manque de lisibilité au profit de quoi? Ne pas taper trois caractères supplémentaires ( aset un espace). Pas la peine.

À des fins d'exagération, jetez un œil à une requête comme celle-ci:

use AdventureWorks2012;
go

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

Pas du code que je voudrais revoir.

Personnellement, je trouve alias = expressionplus facile à lire et à comprendre. La raison en est que lorsque je dépanne une SELECTinstruction contenant de longues expressions, je veux probablement trouver l'expression via le nom de la colonne, et non l'inverse. Vite, trouvez l'expression que l'application voit comme alias2:

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

C'est ma préférence. Le vôtre peut être différent. Il n'y a pas de véritable avantage à utiliser l'un ou l'autre, sauf pour des raisons subjectives / gustatives. L'important est que vous choisissiez une façon de le faire et que vous le fassiez de manière cohérente (et à moins que vous ne jetiez une pièce, soyez en mesure de défendre votre choix lorsque vous affrontez quelqu'un qui aime l'autre sens). Mais si vous écrivez du code pour un DBA aussi difficile que moi, préparez-vous à ce qu'il soit réécrit. :-)

J'ai blogué à ce sujet .

Une chose que je ressens encore plus est l'utilisation de guillemets simples autour des noms d'alias, par exemple

column AS 'alias'
'alias' = column

Une forme est déconseillée, mais les deux sont très difficiles à lire - et de nombreux débutants confondent l'alias avec un littéral de chaîne, car c'est à cela qu'il ressemble. Pour les mêmes raisons, je déteste absolument l'utilisation de guillemets doubles ( "alias"). Si vous devez échapper à votre alias car il s'agit d'un mot réservé ou autrement mal choisi ou formaté, utilisez [square brackets].