Учитывает ли синтаксис SQL регистр?

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

Я не думаю, что SQL Server чувствителен к регистру, по крайней мере, не по умолчанию.

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

select cOL1, col2 FrOM taBLeName WheRE ...

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

Теперь, если вы говорите об именах таблиц / столбцов, то да, но не о самих командах.

Так

SELECT * FROM foo;

такой же как

select * from foo;

но не то же самое, что

select * from FOO;

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

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

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

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

См. Раздел SQL-92. 5.2

В Sql Server это вариант. Включение - отстой.

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

Насколько я понимаю, стандарт SQL требует нечувствительности к регистру. Однако я не верю, что какие-либо базы данных полностью соответствуют стандарту.

MySQL имеет параметр конфигурации как часть своего «строгого режима» (набор с несколькими настройками, которые делают MySQL более совместимым со стандартами) для чувствительных к регистру или нечувствительных к регистру имен таблиц. Независимо от этого параметра имена столбцов по-прежнему нечувствительны к регистру, хотя я думаю, что это влияет на то, как отображаются имена столбцов. Я считаю, что этот параметр является общесистемным для всех баз данных в экземпляре СУБД, хотя сегодня я занимаюсь исследованием, чтобы подтвердить это (и надеюсь, что ответ отрицательный).

Мне нравится, как 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, который обсуждает, желательна ли чувствительность к регистру в СУБД.

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

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

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

Я нашел это сообщение в блоге очень полезным (я не автор). Подводя итоги (пожалуйста, прочтите):

...delimited identifiers are case sensitive ("table_name" != "Table_Name"), while non quoted identifiers are not, and are transformed to upper case (table_name => TABLE_NAME).

Он обнаружил, что DB2, Oracle и Interbase / Firebird на 100% совместимы:

PostgreSQL ... lowercases every unquoted identifier, instead of uppercasing it. MySQL ... file system dependent. SQLite and SQL Server ... case of the table and field names are preserved on creation, but they are completely ignored afterwards.

Спецификация 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-операторы в нижнем регистре, и если вам когда-нибудь понадобится его отформатировать, просто установите плагин, который сделает это за вас. Это применимо только в том случае, если в вашем редакторе кода есть эти плагины. VSCode имеет множество расширений, которые могут это делать.