Чи є різниця між розміщенням псевдоніму стовпця на початку або в кінці визначення стовпця?


12

Я завжди бачив і писав псевдоніми своєї колонки як

SELECT 1 as ColumnName

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

SELECT ColumnName = 1

Чи є різниця в тому, як ці два запити виконуються? Або серед DBA існує стандарт, який слід використовувати?

Особисто я думаю, що 2-го було б легше читати / підтримувати для більш довгих визначень стовпців (хороший приклад тут з цієї статті ), однак я ніколи не бачив 2-го синтаксису, який використовувався раніше, тому мені цікаво, чи є причина, чому я не повинен бути використовуючи його.


2
Зауважте, що форма присвоєння коментарів з псевдонімом коментарів не є переносною, тому, хоча це робить речі досить читабельними, коли ви виконуєте багато похідних робіт стовпців, це може бути прикрою, щоб пізніше перетворити його в іншу СУБД.
Кейд Ру

@Cade Celko постійно твердить про певні речі. Якщо мені доведеться перетворити базу даних коду SQL Server в Oracle або PG або MySQL, псевдонім складу буде найменшим з моїх турбот. Оскільки, на відміну від Celko, я не маю інтересу уникати всіх фірмових функцій у випадку, якщо ми коли-небудь перемістимо всю свою архітектуру до іншого RDBMS. Цікаво, як часто це відбувається насправді поза аудиторією ...
Аарон Бертран

@AaronBertrand Я погоджуюся про масове перетворення. Я перетворив купу матеріалів на Терадата, і це найменша проблема. Що все частіше трапляється зі мною - я імпортую цілі дані необроблених таблиць у свій власний SQL Server і роблю перегляди або запити на ньому чи що я роблю для його аналізу, і тоді я напишу запит або замовити джерело системний діалект, який потрібно викликати з SSIS, або що-небудь, щоб отримати ПРОСТО саме ті дані, які я хочу провести через провід. У цих випадках я свідомо пишу дуже загальний SQL у стилі ANSI. І тоді мені ще доведеться змінити такі речі, як функції дати.
Кейд Ру

Відповіді:


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>на останній рядок визначення стовпця. Але, безумовно, погоджено, це так само особисто, як те, як вам подобається ваша кава.
Thomas Stringer

@ThomasStringer див. Я вважаю за краще, щоб каретка повернула вираз. Якщо рядок починається з AS Aliasцього, ASце не дуже корисно, коли я сканую вертикально певну назву таблиці. Б'юсь об заклад, що ми не погодимось, куди також поставити коми. :-)
Аарон Бертран

Я спробував один раз використати цитати навколо псевдонімів моєї колонки, тому що це зробило їх червоними, які виділялися в SSMS, але роздратування введення ключа цитати так швидко стало для мене занадто багато, і я знову опинився на своїх ледачих шляхах. Крім того, він не працював так, як за призначенням, коли у мене були рядки в запиті. Я, мабуть, дотримуватимусь ASтого, що ми використовуємо зараз (я зазвичай додаю новий рядок раніше, AS ColumnNameщоб вони приблизно вирівнювались), але я згоден, що =це набагато зручніше читати у більш довгих визначеннях стовпців.
Рейчел

2
@AaronBertrand Мій аргумент для того, щоб ставити комами на перше місце, це полегшує визначення рівня стовпця, особливо з багаторядкових визначень стовпців.
Рейчел

1
@AaronBertrand Я зазвичай не працюю з розумно відрезаним кодом>. <
Рейчел
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.