Синтаксис SQL чувствителен к регистру?
Является ли SQL чувствительным к регистру. Я использовал MySQL и SQL Server, которые кажутся нечувствительными к регистру. Это всегда так? Стандарт определяет чувствительность к регистру?
10 ответов
Ключевые слова SQL чувствительны к регистру (SELECT, FROM, WHEREи т. д.), но часто пишутся заглавными буквами. Однако в некоторых настройках имена таблиц и столбцов чувствительны к регистру. MySQL имеет параметр конфигурации, чтобы включить / отключить его. Обычно регистрозависимые имена таблиц и столбцов используются по умолчанию в Linux MySQL, а регистрозависимые используются в Windows по умолчанию, но теперь установщик спрашивал об этом во время установки. Для MSSQL это функция настройки сортировки базы данных.
Это не строго язык SQL, но в SQL Server, если параметры сортировки базы данных чувствительны к регистру, то все имена таблиц чувствительны к регистру.
В спецификации SQL92 говорится, что идентификаторы могут быть заключены в кавычки или не заключены в кавычки. Если обе стороны не заключены в кавычки, они всегда нечувствительны к регистру, например table_name == TAble_nAmE,
Однако идентификаторы в кавычках чувствительны к регистру, например "table_name" != "TAble_naME", Также на основе спецификации, если вы хотите сравнить идентификаторы без кавычек с идентификаторами в кавычках, то идентификаторы без кавычек и кавычек могут считаться одинаковыми, если символы без кавычек пишутся в верхнем регистре, например TABLE_NAME == "TABLE_NAME", но TABLE_NAME != "table_name" или же TABLE_NAME != "TAble_NaMe",
Вот соответствующая часть спецификации (раздел 5.2.13):
13)A <regular identifier> and a <delimited identifier> are equiva-
lent if the <identifier body> of the <regular identifier> (with
every letter that is a lower-case letter replaced by the equiva-
lent upper-case letter or letters) and the <delimited identifier
body> of the <delimited identifier> (with all occurrences of
<quote> replaced by <quote symbol> and all occurrences of <dou-
blequote symbol> replaced by <double quote>), considered as
the repetition of a <character string literal> that specifies a
<character set specification> of SQL_TEXT and an implementation-
defined collation that is sensitive to case, compare equally
according to the comparison rules in Subclause 8.2, "<comparison
predicate>".
Обратите внимание, что, как и в случае с другими частями стандарта SQL, не все базы данных полностью следуют этому разделу. Например, PostgreSQL хранит все идентификаторы без кавычек в нижнем регистре, а не в верхнем, так что table_name == "table_name" (что в точности противоположно стандарту). Кроме того, некоторые базы данных всегда чувствительны к регистру, или чувствительность к регистру зависит от некоторых настроек в БД или зависит от некоторых свойств системы, обычно независимо от того, чувствительна ли к регистру файловая система или нет.
Обратите внимание, что некоторые инструменты базы данных могут отправлять идентификаторы в кавычках все время, поэтому в случаях, когда вы смешиваете запросы, сгенерированные каким-либо инструментом (например, запрос CREATE TABLE, сгенерированный Liquibase или другим инструментом переноса БД), с запросами, сделанными вручную (например, простым выбором JDBC в вашем приложении) вы должны убедиться, что эти случаи совпадают, особенно в базах данных, где идентификаторы в кавычках и без кавычек различаются (DB2, PostgreSQL и т. д.)
В Sql Server это вариант. Включение это отстой.
Я не уверен насчет MySql.
Идентификаторы и зарезервированные слова не должны быть чувствительными к регистру, хотя многие придерживаются соглашения использовать заглавные буквы для зарезервированных слов и регистр Pascal для идентификаторов.
См. SQL-92 Sec. 5,2
Насколько я понимаю, стандарт SQL требует учета регистра. Я не верю, что какие-либо базы данных полностью следуют стандарту.
MySQL имеет параметр конфигурации как часть своего "строгого режима" (набор из нескольких параметров, которые делают MySQL более совместимым со стандартами) для чувствительных к регистру или нечувствительных имен таблиц. Независимо от этого параметра, имена столбцов по-прежнему не чувствительны к регистру, хотя я думаю, что это влияет на способ отображения имен столбцов. Я полагаю, что этот параметр применяется для всего экземпляра во всех базах данных в экземпляре RDBMS, хотя я исследую сегодня, чтобы подтвердить это (и надеюсь, что ответ - нет).
Мне нравится, как Oracle справляется с этим гораздо лучше. В прямом SQL идентификаторы, такие как имена таблиц и столбцов, не чувствительны к регистру. Однако, если по какой-то причине вы действительно хотите получить явный регистр, вы можете заключить идентификатор в двойные кавычки (которые сильно отличаются в Oracle SQL от одинарных кавычек, используемых для включения строковых данных). Так:
SELECT fieldName
FROM tableName;
будет запрашивать имя поля из таблицы, но
SELECT "fieldName"
FROM "tableName";
запросит fieldName из tableName.
Я уверен, что вы могли бы даже использовать этот механизм для вставки пробелов или других нестандартных символов в идентификатор.
В этой ситуации, если по какой-то причине вы посчитали, что имена таблиц и столбцов в явном виде желательны, они были доступны вам, но я все равно остался бы против них.
Мое соглашение, когда я использовал Oracle на ежедневной основе, заключалось в том, что в коде я должен поместить все ключевые слова Oracle SQL в верхний регистр и все идентификаторы в нижний регистр. В документации я бы поставил все имена таблиц и столбцов в верхнем регистре. Это было очень удобно и доступно для чтения (хотя иногда было сложно набирать в коде так много прописных букв - я уверен, что мог бы найти здесь функцию редактора).
На мой взгляд, MySQL особенно плох для того, чтобы отличаться по этому поводу на разных платформах Нам нужно иметь возможность выгружать базы данных в Windows и загружать их в UNIX, и это приводит к катастрофе, если установщик в Windows забыл перевести СУБД в режим с учетом регистра. (Честно говоря, одна из причин того, что это катастрофа, заключается в том, что наши программисты давно приняли неверное решение полагаться на чувствительность к регистру MySQL в UNIX.) Люди, написавшие установщик Windows MySQL, сделали его действительно удобным и Похожа на Windows, и было здорово подойти к тому, чтобы дать людям флажок "Хотите включить строгий режим и сделать MySQL более совместимым со стандартами?" Но для MySQL очень удобно так сильно отличаться от стандарта, а затем усугубить ситуацию, повернувшись и отличаясь от своего фактического стандарта на разных платформах. Я уверен, что в разных дистрибутивах Linux это может усугубиться, поскольку упаковщики для разных дистрибутивов, возможно, иногда включали свои предпочтительные параметры конфигурации MySQL.
Вот еще один вопрос SO, который вступает в обсуждение, если в РСУБД желательна чувствительность к регистру.
Нет. MySQL не чувствителен к регистру и не является стандартом SQL. Это просто обычная практика писать команды в верхнем регистре.
Теперь, если вы говорите об именах таблиц / столбцов, то да, они есть, но не сами команды.
Так
SELECT * FROM foo;
такой же как
select * from foo;
но не такой как
select * from FOO;
Я нашел этот пост очень полезным (я не автор). Подводя итог (пожалуйста, прочитайте, однако):
... идентификаторы с разделителями чувствительны к регистру ("table_name"!= "Table_Name"), а не заключенные в кавычки идентификаторы - нет, и преобразуются в верхний регистр (table_name => TABLE_NAME).
Он обнаружил, что DB2, Oracle и Interbase/Firebird совместимы на 100%:
PostgreSQL... в нижнем регистре каждый без кавычек, а не в верхнем регистре. MySQL ... зависит от файловой системы. SQLite и SQL Server ... регистр имен таблиц и полей сохраняется при создании, но впоследствии полностью игнорируется.
Я не думаю, что SQL Server чувствителен к регистру, по крайней мере, по умолчанию.
Когда я запрашиваю вручную через Management Studio, я постоянно запутываю дело, и оно с радостью принимает его:
select cOL1, col2 FrOM taBLeName WheRE ...
Ключевые слова SQL не чувствительны к регистру.
Имена таблиц, столбцов и т. Д. Имеют чувствительность к регистру, которая зависит от базы данных - вы, вероятно, должны предполагать, что они чувствительны к регистру, если вы не знаете иначе (хотя во многих базах данных это не так; в именах таблиц MySQL ИНОГДА чувствительны к регистру, но большинство других имен нет).
Сравнение данных с использованием =, >, <и т. Д. Учитывает регистр, который зависит от параметров сортировки, которые используются в конкретной базе данных, таблице или даже соответствующем столбце. Однако это нормально, чтобы поддерживать сопоставление в базе данных достаточно согласованным. У нас есть несколько столбцов, которые должны хранить значения с учетом регистра; у них специально установлено сопоставление.
Получите лучшее из обоих миров
В наши дни вы можете просто писать все свои sql-операторы в нижнем регистре, и если вам когда-нибудь понадобится его отформатировать, просто установите плагин, который сделает это за вас. Это применимо только в том случае, если в вашем редакторе кода есть эти плагины. VSCode имеет множество расширений, которые могут это сделать.