Подтвердить что ты не робот

Какие символы действительны в имени базы данных SQL Server?

Мы собираемся предоставить нашим клиентам инструмент, который (помимо всего прочего) создает новую базу данных SQL Server, и я хочу иметь возможность выполнять базовую проверку на имя базы данных, которое они предоставляют. Документация SQL Server объясняет, какие символы действительны в имени базы данных. Однако документация, по-видимому, неверна, поскольку я могу успешно создавать базы данных, чьи имена нарушают документированные правила.

В соответствии с документацией SQL Server для CREATE DATABASE имена баз данных должны соответствовать правилам для идентификаторов; и правила для идентификаторов зависят от уровня совместимости базы данных. Когда уровень совместимости равен 100 (который, согласно SQL Server Management Studio, означает "SQL Server 2008" ), имя должно начинаться с буквы Unicode, _, @ или #; за которыми следуют одна или несколько букв, цифр, @, $, # или _. В документации четко указано, что встроенные пространства или специальные символы не разрешены.

Это летит перед доступными доказательствами, потому что я могу использовать SQL Server Management Studio для создания базы данных с именем This & That | "Other" - которая не только содержит встроенные пространства (явно запрещенные), но и содержит специальные символы (|, "), которые даже не действительны в имени файла. Я проверил, и уровень совместимости базы данных действительно "SQL Server 2008 (100)", хотя его имя задокументировано как недопустимое на этом уровне совместимости.

Черт, я даже могу сделать CREATE DATABASE " " (да, это одно пространство), что доказывает, что первый символ не должен быть буквой, подчеркиванием, знаком или значком фунта.

Итак, я думаю, мой вопрос в том, какие символы действительны в имени базы данных SQL Server? Существуют ли документированные правила, совместимые с фактическим поведением SQL Server?

4b9b3361

Ответ 1

правила для идентификаторов в конце:

Когда идентификаторы используются в Операторы Transact-SQL, идентификаторы, которые не соответствуют эти правила должны быть разделены двойные кавычки или скобки.

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

Если правила для регулярных идентификаторов соблюдаются, вы можете использовать имя своей базы данных без кавычек/скобок.

Следующие инструкции в порядке

CREATE DATABASE [conformingName]
CREATE DATABASE conformingName
CREATE DATABASE [This & That | "Other"]

но не

CREATE DATABASE This & That | "Other"

EDIT:

Я согласен с тем, что это не так, как можно было бы понять связанную документацию: что должно соответствовать правилам для идентификаторов, означает, что если правила не будут применяться больше, как только будет заключен идентификатор? Вопрос о включении несоответствующих идентификаторов должен быть частью правил.

Ответ 2

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

Поскольку вы используете кавычки вокруг идентификатора, это идентификатор с разделителями, и вы не ограничены правилами регулярных идентификаторов.

Без разделителей вы можете создавать базы данных с идентификаторами, которые следуют правилам регулярных идентификаторов:

create database db_name

С разделителями вы можете использовать почти все:

create database "That a funny name, isn't it?"

create database [)(/%Q)/#&%¤)Q/#)!]

Ответ 3

Лично я бы ограничил их алфавитом и цифрами, и ничего больше (ну возможно и _). Без пробелов, смешных символов, никаких возвратов каретки и т.д. Это самое безопасное, что вы можете сделать.

Ответ 4

Ограниченные имена - окруженные квадратными скобками или двойными кавычками (если QUOTED_IDENTIFIER установлено в ON) - может содержать в основном что угодно, кроме самих разделителей, Можно даже использовать разделители внутри имени с некоторой логикой выхода. Обратите внимание, что только экранирующий escape-символ должен быть экранирован. В первом примере ниже одиночный экземпляр символа открытия открытия в имени не должен быть экранирован, тогда как закрывающий escape-символ должен быть экранирован (путем замены одного экземпляра на два). Я предполагаю, что логика здесь заключается в том, что любой код, анализирующий эти утверждения, ищет закрывающий escape-символ и не интересуется вложенными открывающимися escape-символами.

  • [Тест [Тест] → Тест [Тест
  • [Тест]] Тест] → Тест] Тест

Ниже приведено описание правил, связанных с именами идентификаторов без ограничений (без кавычек) в SQL Server 2012. Это выдержка из документа Руководство по миграции из MySQL к SQL Server 2012.

Имена объектов схемы

В SQL Server 2012 имя объекта может содержать до 128 символов.

Идентификаторы без кавычек должны соответствовать следующим правилам:

  • Первый символ должен быть буквенно-цифровым, подчеркиванием (_), знаком at (@) или значком числа (#).
  • Последующие символы могут содержать буквенно-цифровые символы, знак подчеркивания, знак (@), знак числа или знак доллара.
  • Идентификатор не должен быть зарезервированным словом Transact-SQL. Руководство по миграции из MySQL в SQL Server 2012 8
  • Встраиваемые пробелы или специальные символы не допускаются.

Идентификаторы, начинающиеся с знака @или числа, имеют специальные значения. Идентификаторы, начинающиеся с @, являются локальными именами переменных. Те, которые начинают с знаком числа - временные имена таблиц.

Чтобы указать имя идентификатора в Transact-SQL, вы должны использовать квадрат скобки ([]).