Я видел, как некоторые люди используют псевдонимы столбцов в одинарных кавычках, например:
select orderID 'Order No' from orders
и другие используют квадратные скобки, например:
select orderID [Order No] from orders
Я обычно использую квадратные скобки. Есть ли какие-то предпочтения / различия?
Чтобы ответить на вопрос «есть ли какие-то предпочтения / различия»:
Да, предпочтений столько же, сколько и мнений, но будьте осторожны, чьи предпочтения вы принимаете.
Лучше всего писать переносимый SQL, если это не требует дополнительных усилий.
Для вашего конкретного образца так же легко написать переносимый запрос ...
select OrderId as "Order Id" from Orders
... как написать непереносимый:
select OrderId as [Order Id] from Orders
Желательно не писать нестандартный SQL, когда есть эквивалентная переносимая форма с таким же количеством нажатий клавиш.
Распространение [] для экранирования связано с такими инструментами, как SQL Server Management Studio и построители запросов MS Access, которые лениво избегают всего. Это может никогда не прийти в голову разработчику, который посвятил свою карьеру SQL Server, но скобки привели к большим расходам на протяжении многих лет при переносе приложений Access и SQL Server на другие платформы баз данных. То же самое и с инструментами Oracle, которые цитируют все. Неподготовленные разработчики рассматривают DDL как примеры, а затем переходят к тому же стилю при написании от руки. Это сложный цикл, который нужно разорвать до тех пор, пока инструменты не улучшатся и мы не потребуем лучшего. В Oracle цитирование в сочетании со смешанным регистром приводит к чувствительным к регистру базам данных. Я видел проекты, в которых люди цитировали каждый идентификатор в базе данных, и у меня было ощущение, что я попал в The Land of The Lost, где разработчики развивались на острове без документации или статей о передовом опыте.
Если вы с самого начала пишете свой DDL с нормализованными допустимыми идентификаторами (используйте OrderId или order_Id вместо [Order Id], вы не беспокоитесь о мифическом ключевом слове, которому могут потребоваться escape-символы; база данных сообщит вам, когда вы Я использовал зарезервированное слово. Я могу по пальцу сосчитать, сколько раз мы когда-либо обновляли приложение с одной версии SQL Server до другой и имели какие-либо поломки из-за новых зарезервированных слов.
Это часто является предметом жарких споров, поэтому, если вы подумаете по-другому:
Программисты на C # не избегают всех своих переменных с помощью @, даже если это разрешено. Это было бы странной практикой и предметом насмешек в StackOverflow. Экранирование должно быть для крайних случаев. Но те же разработчики, которые пишут соответствующие идентификаторы C #, не возражают против экранирования каждого отдельного идентификатора в своем SQL, написав ужасно уродливый, непереносимый «код» SQL. В качестве консультанта я встречал более чем одного программиста SQL Server, который искренне считал [] обязательным синтаксисом. Я не виню разработчиков; Я виню инструменты.
C# programmers don't escape all their variables with @, even though it is legal to do so.
- person RBT; 12.08.2016
Действительны 's, зависит от того, какие настройки у вас в силе. И вы пропустили ". См. идентификаторы с разделителями:
Если для QUOTED_IDENTIFIER установлено значение ON, SQL Server следует правилам ISO для использования двойных кавычек () и одинарных кавычек (') в операторах SQL. Например:
Двойные кавычки можно использовать только для ограничения идентификаторов. Их нельзя использовать для разделения символьных строк.
Для заключения символьных строк необходимо использовать одинарные кавычки. Их нельзя использовать для разграничения идентификаторов.
Когда QUOTED_IDENTIFIER имеет значение OFF, SQL Server использует следующие правила для одинарных и двойных кавычек:
Кавычки нельзя использовать для обозначения идентификаторов. Вместо этого в качестве разделителей следует использовать скобки.
Для заключения символьных строк можно использовать одинарные или двойные кавычки.
И наконец:
Разделители в скобках можно использовать всегда, независимо от настройки QUOTED_IDENTIFIER
Где во всех приведенных выше кавычках, когда они ссылаются на скобки, они имеют в виду [] скобки.
select 1 as 'foo'.
- person Martin Smith; 12.04.2015
Одиночные кавычки более читабельны. Как показано выше, выделено красным.
MySQL использует обратные кавычки для экранирования специальных символов.
MSSQL может использовать «двойные кавычки» или [скобки] для идентификаторов (таблиц, столбцов и т. Д.)
и «одинарные кавычки» для символьных строк или псевдонимов.
Квадратные скобки используются в основном для инкапсуляции объектов, чтобы специальные символы, такие как пробелы, точки или дефисы, не вызывали синтаксических ошибок.
Я бы порекомендовал использовать ключевое слово as перед псевдонимами столбцов - это намного удобнее.
select [column with spaces] as 'my col' from "table with spaces" where n = 'foo'
select "column with spaces" as 'my col' from [table with spaces] where n = 'foo'
select sum ('foo') from (select 1 as 'foo') x
- person Justin Grant; 15.08.2015
Ценовой подход позволяет вам сделать это:
SELECT 1 AS 'bla[]bla'
select 1 as [bla'bla]
- person Mike Causer; 29.10.2013
QUOTENAME, можно разделить имя, содержащее квадратные скобки, с помощью квадратные скобки образуют: [bla[]]bla]
- person Damien_The_Unbeliever; 29.10.2013
Благодарим Джастина Гранта в комментарии к этой теме - публикация этого сообщения является полным ответом для наглядности.
Если мы согласимся с тем, что в целом предпочтения субъективны, но желательна согласованность, то с точки зрения реальных различий есть веская причина не использовать одинарные кавычки '. Если вам нужно использовать, например, агрегатная функция в столбце, имя которого требует цитирования, одинарные кавычки вызовут у вас проблемы (код напрямую копирует / вставляет из комментария Джастина):
select sum ('foo') from (select 1 as 'foo') x
На мой взгляд, это достаточная причина не использовать одинарные кавычки - бывают случаи, когда вы не можете их использовать, что мешает согласованности.
Таким образом, двойные кавычки " или квадратные скобки [] - это единственные пути. Это сводится к тому, какой тип согласованности вы цените больше - согласованность с кодом, который могут создавать специальные инструменты SQL Server, в котором будут использоваться скобки, или соблюдение стандарта ANSI, который определяет двойные кавычки. В достаточно развитой среде Microsoft скобки могут иметь больше смысла. В противном случае, возможно, лучше использовать двойные кавычки.
