Есть ли разница между размещением псевдонима столбца в начале или конце определения столбца?

12

Я всегда видел и писал свои псевдонимы столбцов как

SELECT 1 as ColumnName

но сегодня наткнулся на запрос, который использовал

SELECT ColumnName = 1

Есть ли разница в том, как выполняются эти два запроса? Или среди администраторов баз данных есть какой-то стандарт?

Лично я думаю, что 2-й будет легче читать / поддерживать для более длинных определений столбцов (хороший пример здесь из этой статьи ), однако я никогда не видел, чтобы 2-й синтаксис использовался до сегодняшнего дня, поэтому мне интересно, есть ли какая-то причина, по которой мне не следует используй это.

Рейчел
источник
2
Обратите внимание, что форма присвоения псевдонимов комментариев не переносима, поэтому, хотя она делает вещи достаточно читабельными, когда вы выполняете МНОГО работы с производными столбцами, может быть раздражает необходимость позднее преобразовывать ее в другую СУБД.
Cade Roux
@Cade Celko постоянно приводит аргументы в пользу определенных вещей. Если мне придется преобразовать кодовую базу SQL Server в Oracle, PG или MySQL, состав псевдонимов будет меньше всего меня беспокоить. Поскольку, в отличие от Celko, я не заинтересован в том, чтобы избегать всех проприетарных функций на случай, если мы когда-нибудь переместим всю нашу архитектуру на другую СУБД. Интересно, как часто это действительно происходит за пределами классной комнаты ...
Аарон Бертран
@AaronBertrand Я согласен с массовым преобразованием. Я преобразовал кучу вещей в Teradata, и это меньше всего проблем. Что по-прежнему происходит со мной чаще, так это то, что я буду импортировать все необработанные данные таблиц в свой собственный SQL Server и создавать представления или запросы к ним или все, что я делаю для их анализа, а затем я напишу запрос или процедуру для источника системный диалект, который будет вызываться из SSIS или как угодно, чтобы получить ТОЛЬКО те данные, которые мне нужны, по проводам. В этих случаях я сознательно пишу очень общий SQL в стиле ANSI. И тогда мне все еще нужно изменить вещи, как функции даты.
Cade Roux

Ответы:

17

Нет никакой разницы в основной функциональности двух типов псевдонимов (в asотличие от =). Все сводится к тому, что вы упомянули: удобочитаемость и ремонтопригодность.

На мой взгляд, прежний ( <Expression> as <Alias>) гораздо более читабелен, так как не требует пояснений. Когда у вас есть, SELECT ColumnName = 1я думаю, было бы довольно легко ошибочно принять это за установку переменной в те долгие усталые ночи. Вы можете ошибиться, так как SELECT @ColumnName = 1и это будет совершенно другая функциональность. Поэтому, чтобы обойти любую возможность запроса "двойного взгляда" или, что еще хуже ... ошибки в понимании / кодировании, я иду с SELECT 1 as ColumnName100% времени.

Личные предпочтения, но последовательность (для себя и внутри вашей команды) является королем . Что бы вы ни находили легким, делайте это и делайте это все время. Нет ничего более разочаровывающего, чем переключаться взад и вперед для кого-то, кто занимается поиском и устранением неисправностей / просмотром / обслуживанием кода.

Третий не упомянутый способ заключается в использовании <Expression> <Alias>. Другими словами, ваш второй путь без asключевого слова. Я думаю, что это так же плохо, как =символ. Не хватает читабельности при выигрыше чего? Не вводите три лишних символа ( asи пробел). Не стоит того.

В целях преувеличения взгляните на такой запрос:

use AdventureWorks2012;
go

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

Не код, который я хотел бы рассмотреть.

Томас Стрингер
источник
5
меня всегда раздражает видеть последнее, где они исключают ключевое слово «как». Не требуется, но боль читать при просмотре кода.
10

Лично мне alias = expressionлегче читать и понимать. Причина в том, что когда я устраняю неполадки в SELECTвыражении, содержащем длинные выражения, я, вероятно, хочу найти выражение по имени столбца, а не наоборот. Быстро, найдите выражение, которое приложение видит как alias2:

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

Это мое предпочтение. Ваш может быть другим. Нет реального преимущества в использовании того или другого, кроме как по субъективным / вкусовым причинам. Важно то, что вы выбираете один способ сделать это и делать это последовательно (и если вы не подбросите монетку, сможете защитить свой выбор, когда столкнетесь с кем-то, кому нравится другой способ). Но если вы пишете код для DBA, такой же суетливый, как и я, будьте готовы к тому, что он будет переписан. :-)

Я писал об этом в блоге .

Одна вещь, в которой я чувствую себя еще сильнее, это использование одинарных кавычек вокруг псевдонимов

column AS 'alias'
'alias' = column

Одна форма устарела, но обе очень трудны для чтения - и многие новички принимают псевдоним как строковый литерал, так как он выглядит так. По тем же причинам я абсолютно не люблю использование двойных кавычек ( "alias"). Если вам нужно экранировать псевдоним, потому что это зарезервированное слово или оно неправильно выбрано или отформатировано, используйте [square brackets].

Аарон Бертран
источник
2
Полностью согласен с аспектом цитаты. Что касается длинного выражения, то я лично использую возврат каретки и табуляцию новой строки, а затем помещаю as <Alias>в последнюю строку определения столбца. Но определенно согласился, это так же личное, как то, как тебе нравится твой кофе.
Томас Стрингер
@ThomasStringer вижу, я бы предпочел карету вернуть выражение. Если строка начинается с AS Aliasэтого, ASэто не очень полезно, когда я сканирую по вертикали конкретное имя таблицы. Могу поспорить, мы не согласны с тем, где поставить запятые тоже. :-)
Аарон Бертран
Я однажды пытался использовать одинарные кавычки вокруг псевдонимов столбцов, потому что это делало их красными, которые выделялись в SSMS, но раздражение от быстрого ввода ключа кавычки стало слишком большим для меня, и я вернулся к своим ленивым путям. Кроме того, это не сработало по назначению, когда в моем запросе были строки. Я, вероятно, буду придерживаться, ASпоскольку именно это мы и используем сейчас (обычно я добавляю новую AS ColumnNameстроку раньше, чтобы они примерно выровнялись), но я согласен, что =это намного удобнее для чтения в более длинных определениях столбцов.
Рэйчел
2
@AaronBertrand Мой аргумент в пользу того, чтобы ставить запятые в первую очередь, заключается в том, что с его помощью легче определить, где начинается определение столбца, особенно с многострочными определениями столбцов.
Рэйчел
1
@AaronBertrand Я обычно не работаю с кодом с отступами>. <
Рэйчел