Синтаксис SQL чувствителен к регистру?

Является ли SQL чувствительным к регистру. Я использовал MySQL и SQL Server, которые кажутся нечувствительными к регистру. Это всегда так? Стандарт определяет чувствительность к регистру?

В SQL Ключевые слова нечувствительны к регистру ( SELECT, FROM, WHEREи т.д.), но часто пишутся заглавными буквами. Однако в некоторых настройках имена таблиц и столбцов чувствительны к регистру. MySQL имеет параметр конфигурации, чтобы включить / отключить его. Обычно регистрозависимые имена таблиц и столбцов используются по умолчанию в Linux MySQL, а регистрозависимые используются в Windows по умолчанию, но теперь установщик спрашивал об этом во время установки. Для MSSQL это функция настройки сортировки базы данных.

Вот страница MySQL о чувствительности к регистру имен

Вот статья в MSDN о сопоставлениях для MSSQL

Это не строго язык SQL, но в SQL Server, если параметры сортировки базы данных чувствительны к регистру, все имена таблиц чувствительны к регистру.

В Sql Server это опция . Включение это отстой.

Я не уверен насчет MySql.

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

См. SQL-92 Sec. 5,2

В спецификации 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 Server чувствителен к регистру, по крайней мере, по умолчанию.

Когда я запрашиваю вручную через Management Studio, я все время путаю дело, и оно с радостью принимает его:

select cOL1, col2 FrOM taBLeName WheRE ...

Ключевые слова SQL не чувствительны к регистру.

Имена таблиц, столбцов и т. Д. Имеют чувствительность к регистру, которая зависит от базы данных - вы, вероятно, должны предполагать, что они чувствительны к регистру, если вы не знаете иначе (хотя во многих базах данных это не так; в именах таблиц MySQL ИНОГДА чувствительны к регистру, но большинство других имен нет).

Сравнение данных с использованием =,>, <и т. Д. Учитывает регистр, который зависит от параметров сортировки, которые используются в конкретной базе данных, таблице или даже соответствующем столбце. Тем не менее, это нормально, чтобы поддерживать сопоставление в базе данных достаточно согласованным. У нас есть несколько столбцов, которые должны хранить значения с учетом регистра; у них специально установлено сопоставление.

Иметь лучшее из обоих миров

В наши дни вы можете просто написать все свои SQL-выражения в нижнем регистре, и если вам когда-нибудь понадобится отформатировать их, просто установите плагин, который сделает это за вас. Это применимо, только если в вашем редакторе кода есть эти плагины. VSCode имеет много расширений, которые могут сделать это.