Я всегда видел и писал свои псевдонимы столбцов как
SELECT 1 as ColumnName
но сегодня наткнулся на запрос, который использовал
SELECT ColumnName = 1
Есть ли разница в том, как выполняются эти два запроса? Или среди администраторов баз данных есть какой-то стандарт?
Лично я думаю, что 2-й будет легче читать / поддерживать для более длинных определений столбцов (хороший пример здесь из этой статьи ), однако я никогда не видел, чтобы 2-й синтаксис использовался до сегодняшнего дня, поэтому мне интересно, есть ли какая-то причина, по которой мне не следует используй это.
sql-server
t-sql
best-practices
Рейчел
источник
источник
Ответы:
Нет никакой разницы в основной функциональности двух типов псевдонимов (в
as
отличие от=
). Все сводится к тому, что вы упомянули: удобочитаемость и ремонтопригодность.На мой взгляд, прежний (
<Expression> as <Alias>
) гораздо более читабелен, так как не требует пояснений. Когда у вас есть,SELECT ColumnName = 1
я думаю, было бы довольно легко ошибочно принять это за установку переменной в те долгие усталые ночи. Вы можете ошибиться, так какSELECT @ColumnName = 1
и это будет совершенно другая функциональность. Поэтому, чтобы обойти любую возможность запроса "двойного взгляда" или, что еще хуже ... ошибки в понимании / кодировании, я иду сSELECT 1 as ColumnName
100% времени.Личные предпочтения, но последовательность (для себя и внутри вашей команды) является королем . Что бы вы ни находили легким, делайте это и делайте это все время. Нет ничего более разочаровывающего, чем переключаться взад и вперед для кого-то, кто занимается поиском и устранением неисправностей / просмотром / обслуживанием кода.
Третий не упомянутый способ заключается в использовании
<Expression> <Alias>
. Другими словами, ваш второй путь безas
ключевого слова. Я думаю, что это так же плохо, как=
символ. Не хватает читабельности при выигрыше чего? Не вводите три лишних символа (as
и пробел). Не стоит того.В целях преувеличения взгляните на такой запрос:
Не код, который я хотел бы рассмотреть.
источник
Лично мне
alias = expression
легче читать и понимать. Причина в том, что когда я устраняю неполадки вSELECT
выражении, содержащем длинные выражения, я, вероятно, хочу найти выражение по имени столбца, а не наоборот. Быстро, найдите выражение, которое приложение видит какalias2
:Это мое предпочтение. Ваш может быть другим. Нет реального преимущества в использовании того или другого, кроме как по субъективным / вкусовым причинам. Важно то, что вы выбираете один способ сделать это и делать это последовательно (и если вы не подбросите монетку, сможете защитить свой выбор, когда столкнетесь с кем-то, кому нравится другой способ). Но если вы пишете код для DBA, такой же суетливый, как и я, будьте готовы к тому, что он будет переписан. :-)
Я писал об этом в блоге .
Одна вещь, в которой я чувствую себя еще сильнее, это использование одинарных кавычек вокруг псевдонимов
Одна форма устарела, но обе очень трудны для чтения - и многие новички принимают псевдоним как строковый литерал, так как он выглядит так. По тем же причинам я абсолютно не люблю использование двойных кавычек (
"alias"
). Если вам нужно экранировать псевдоним, потому что это зарезервированное слово или оно неправильно выбрано или отформатировано, используйте[square brackets]
.источник
as <Alias>
в последнюю строку определения столбца. Но определенно согласился, это так же личное, как то, как тебе нравится твой кофе.AS Alias
этого,AS
это не очень полезно, когда я сканирую по вертикали конкретное имя таблицы. Могу поспорить, мы не согласны с тем, где поставить запятые тоже. :-)AS
поскольку именно это мы и используем сейчас (обычно я добавляю новуюAS ColumnName
строку раньше, чтобы они примерно выровнялись), но я согласен, что=
это намного удобнее для чтения в более длинных определениях столбцов.