Учитывается регистр SQL. Я использовал MySQL и SQL Server, которые кажутся случайными. Это всегда так? Стандарт определяет чувствительность к регистру?
Является ли регистр синтаксиса SQL чувствительным?
Ответ 1
Ключевые слова SQL не чувствительны к регистру (SELECT, FROM, WHERE и т.д.), но часто записываются во всех кепках. Однако в некоторых настройках имена таблиц и столбцов чувствительны к регистру. У MySQL есть опция конфигурации для включения/выключения. Обычно регистрозависимые имена таблиц и столбцов являются стандартными для Linux MySQL и без учета регистра, которые по умолчанию используются в Windows, но теперь установщик спросил об этом во время установки. Для MSSQL это функция настройки сортировки базы данных.
Вот страница MySQL о чувствительности к регистру по умолчанию
Вот статья в MSDN о сопоставлениях для MSSQL
Ответ 2
Это не строго язык SQL, но в SQL Server, если сортировка базы данных чувствительна к регистру, все имена таблиц чувствительны к регистру.
Ответ 3
Идентификаторы и зарезервированные слова не должны быть чувствительны к регистру, хотя многие из них следуют за соглашением использовать кавычки для зарезервированных слов и случай Паскаля для идентификаторов.
См. SQL-92 Раздел. 5.2
Ответ 4
В Sql Server это вариант. Включение его в отстой.
Я не уверен в MySql.
Ответ 5
Я понимаю, что стандарт 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.
Here другой вопрос SO, который обсуждает, нужна ли чувствительность к регистру в РСУБД.
Ответ 6
спецификация 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, например, хранит все некотируемые идентификаторы с нижним регистром вместо uppercased, поэтому TABLE_NAME == "TABLE_NAME" (что точно соответствует стандарту). Кроме того, некоторые базы данных нечувствительны к регистру все время, или чувствительность к регистру зависит от некоторых параметров в БД или зависит от некоторых свойств системы, как правило, зависит от того, является ли файловая система чувствительной к регистру или нет.
Обратите внимание, что некоторые инструменты базы данных могут отправлять теги, которые котируются все время, поэтому в случаях, когда вы смешиваете запросы, сгенерированные каким-то инструментом (например, запрос CREATE TABLE, созданный Liquibase или другим инструментом миграции базы данных), с запросами вручную (например, просто выберите JDBC в своем приложении), вы должны убедиться, что дела совместимы, особенно в базах данных, где котируемые и некотируемые идентификаторы отличаются (DB2, PostgreSQL и т.д.).
Ответ 7
Я нашел этот пост в блоге, чтобы быть очень полезным (я не автор). Подведение итогов (пожалуйста, прочитайте, хотя):
... идентификаторы с разделителями чувствительны к регистру ( "table_name"!= "Table_Name" ), в то время как идентификаторы без кавычек не являются и преобразуются в верхний регистр (table_name = > TABLE_NAME).
Он обнаружил, что DB2, Oracle и Interbase/Firebird соответствуют 100%:
PostgreSQL... управляет каждым некотируемым идентификатором, а не верхним. MySQL... зависит от файловой системы. SQLite и SQL Server... случай имен таблиц и полей сохраняется при создании, но после этого они полностью игнорируются.
Ответ 8
Нет. MySQL не чувствителен к регистру, и ни один из них не является стандартом SQL. Это просто обычная практика написания команд в верхнем регистре.
Теперь, если вы говорите о именах таблиц и столбцов, то да, они есть, но не сами команды.
Итак,
SELECT * FROM foo;
совпадает с
SELECT * FROM foo;
но не совпадает с
SELECT * FROM foo;
Ответ 9
SQL-ключевые слова сами по себе нечувствительны к регистру.
Имена таблиц, столбцов и т.д. имеют чувствительность к регистру, зависящую от базы данных. Вероятно, вы должны предположить, что они чувствительны к регистру, если вы не знаете иначе (во многих базах данных их нет, а в именах таблиц MySQL - SOMETIMES с учетом регистра но большинство других имен нет).
Сравнение данных с использованием =, > , < и т.д., имеет информацию о случаях, которая зависит от настроек сортировки, которые используются в отдельной базе данных, таблице или столбце, о котором идет речь. Тем не менее, это нормально, чтобы держать сопоставление достаточно согласованным в базе данных. У нас есть несколько столбцов, которые должны хранить значения, чувствительные к регистру; они имеют определенную сортировку.
Ответ 10
Я не думаю, что SQL Server чувствителен к регистру, по крайней мере, не по умолчанию.
Когда я запрашиваю вручную через Management Studio, я все время исповедую дело, и он с готовностью принимает его:
select cOL1, col2 FrOM taBLeName WheRE ...