Является ли SQL чувствительным к регистру. Я использовал MySQL и SQL Server, которые кажутся нечувствительными к регистру. Это всегда так? Стандарт определяет чувствительность к регистру?
Ответы:
В SQL Ключевые слова нечувствительны к регистру ( SELECT, FROM, WHEREи т.д.), но часто пишутся заглавными буквами. Однако в некоторых настройках имена таблиц и столбцов чувствительны к регистру. MySQL имеет параметр конфигурации, чтобы включить / отключить его. Обычно регистрозависимые имена таблиц и столбцов используются по умолчанию в Linux MySQL, а регистрозависимые используются в Windows по умолчанию, но теперь установщик спрашивал об этом во время установки. Для MSSQL это функция настройки сортировки базы данных.
В Sql Server это опция . Включение это отстой.
Я не уверен насчет MySql.
В спецификации 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 требует учета регистра. Я не верю, что какие-либо базы данных полностью следуют стандарту.
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 не чувствительны к регистру.
Имена таблиц, столбцов и т. Д. Имеют чувствительность к регистру, которая зависит от базы данных - вы, вероятно, должны предполагать, что они чувствительны к регистру, если вы не знаете иначе (хотя во многих базах данных это не так; в именах таблиц MySQL ИНОГДА чувствительны к регистру, но большинство других имен нет).
Сравнение данных с использованием =,>, <и т. Д. Учитывает регистр, который зависит от параметров сортировки, которые используются в конкретной базе данных, таблице или даже соответствующем столбце. Тем не менее, это нормально, чтобы поддерживать сопоставление в базе данных достаточно согласованным. У нас есть несколько столбцов, которые должны хранить значения с учетом регистра; у них специально установлено сопоставление.
Иметь лучшее из обоих миров
В наши дни вы можете просто написать все свои SQL-выражения в нижнем регистре, и если вам когда-нибудь понадобится отформатировать их, просто установите плагин, который сделает это за вас. Это применимо, только если в вашем редакторе кода есть эти плагины. VSCode имеет много расширений, которые могут сделать это.