Синтаксис mysql чувствителен к регистру? могу ли я написать: select, где? [Дубликат]

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

Я не уверен в MySql.

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

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

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

So

SELECT * FROM foo;

совпадает с

select * from foo;

, но не совпадает с

select * from FOO;

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

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

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

SELECT fieldName
FROM tableName;

будет запрашивать имя поля из tablename, но

SELECT "fieldName"
FROM "tableName";

будет запрашивать имя поля из tableName.

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

В этой ситуации, если по какой-то причине вы нашли желаемые имена столбцов и столбцов с явным образом, они были доступны вам, но все равно что я бы настоятельно рекомендовал.

Моя конвенция, когда я ежедневно применяла Oracle, заключалась в том, что в коде я бы поставил все ключевые слова Oracle SQL в верхнем регистре и все идентификаторы в нижнем регистре. В документации я бы поместил все имена таблиц и столбцов в верхний регистр. Это было очень удобно и удобочитаемо, чтобы иметь возможность сделать это (хотя иногда и боль, чтобы набрать так много капиталов в коде - я уверен, что я мог бы найти функцию редактора, чтобы помочь здесь).

На мой взгляд, MySQL особенно плохо разбирается в этом на разных платформах. Нам нужно иметь возможность удалять базы данных в Windows и загружать их в UNIX, и это катастрофа, если установщик в Windows забыл включить RDBMS в режим, чувствительный к регистру. (Чтобы быть справедливым, часть причины, по которой это катастрофа, - это то, что наши кодеры давно уже ошибочно полагались на чувствительность к регистру MySQL в UNIX.) Люди, которые написали установщик Windows MySQL, сделали это очень удобным и Windows-like, и было здорово продвигаться к тому, чтобы дать людям чекбокс, чтобы сказать: «Хочешь включить строгий режим и сделать MySQL более стандартным?» Но MySQL очень удобен в том, что он отличается от стандарта стандартным, а затем ухудшается, оборачиваясь и отличаясь от своего собственного стандарта де-факто на разных платформах. Я уверен, что в разных дистрибутивах Linux это может быть еще более усугублено, так как упаковщики для разных дистрибутивов, вероятно, иногда использовали свои собственные предпочтительные настройки конфигурации MySQL.

Здесь Вопрос, который обсуждается, если чувствительность к регистру желательно в РСУБД.

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

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

select cOL1, col2 FrOM taBLeName WheRE ...

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

Имена таблиц, столбцов и т. д. имеют чувствительность к регистру, зависящую от базы данных. Вероятно, вы должны предположить, что они чувствительны к регистру, если вы не знаете иначе (во многих базах данных они не так, но в именах таблиц MySQL есть SOMETIMES с учетом регистра, но большинство других имен нет).

Сравнение данных с использованием =,>, & lt; и т. д., имеет информацию о случаях, которая зависит от настроек сортировки, которые используются в отдельной базе данных, таблице или столбце, о котором идет речь. Это нормально, однако, держать сопоставление достаточно последовательным в базе данных. У нас есть несколько столбцов, которые должны хранить значения, чувствительные к регистру; они имеют определенную настройку.

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

... идентификаторы с разделителями чувствительны к регистру ("table_name"! = "Table_Name"), тогда как идентификаторы без кавычек не являются и преобразуются в верхний регистр (table_name => TABLE_NAME).

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

PostgreSQL ... содержит нижний регистр каждого некотируемого идентификатора , а не верхняя часть его. MySQL ... зависит от файловой системы. SQLite и 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 и т. Д.)

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

См. SQL-92 Sec. 5.2 [/ д2]