Является ли SQL чувствительным к регистру. Я использовал MySQL и SQL Server, которые кажутся случайными. Это всегда так? Стандарт определяет чувствительность к регистру?Является ли синтаксис SQL чувствительным к регистру?
В SQL Ключевые слова нечувствительны к регистру (SELECT, FROM, WHERE и т.д.), но часто пишутся во всех шапках. Однако в некоторых настройках имена таблиц и столбцов чувствительны к регистру. У MySQL есть опция конфигурации для включения/выключения. Обычно регистрозависимые имена таблиц и столбцов являются стандартными для Linux MySQL и без учета регистра, которые по умолчанию используются в Windows, но теперь установщик спросил об этом во время установки. Для MSSQL это функция настройки сортировки базы данных.
Некоторые системы (например, PostgreSQL) чувствительны к регистру в именах таблиц и столбцов, но стараются скрыть их через нижний регистр или верхний регистр всех имен перед их просмотром. В этих системах вам нужно будет заключить имя таблицы в «двойные кавычки», чтобы убедиться, что точное имя, которое вы ввели, просматривается. – 2008-09-30 17:12:52
", но часто пишутся во всех кепках" Я не согласен, это просто предпочтение, я всегда видел обратное на самом деле – BlackTigerX 2009-02-06 17:53:45
Это не строго язык SQL, но в SQL Server, если сортировка базы данных чувствительна к регистру, то все имена таблиц чувствительны к регистру.
Я не думаю, что SQL Server чувствителен к регистру, по крайней мере, не по умолчанию.
Когда я запрашивая вручную через Management Studio, я испортит дело все время, и он бодро принимает это:
select cOL1, col2 FrOM taBLeName WheRE ...
No. MySQL не чувствителен к регистру, и ни один не является стандартом SQL. Это обычная практика для написания команд в верхнем регистре.
Теперь, если вы говорите о именах таблиц и столбцов, то да, они есть, но не сами команды.
Так
SELECT * FROM foo;
такая же, как
select * from foo;
, но не такой же, как
select * from FOO;
В большинстве СУБД имена таблиц также не чувствительны к регистру. По крайней мере, не по умолчанию. MySQL является самым заметным исключением из этого правила. – 2013-07-12 08:35:50
Идентификаторы и зарезервированные слова не должны быть чувствительны к регистру, хотя многие из них следуют конвенции использовать капиталы для зарезервированных слов и Паскаль случае для идентификаторов.
См. SQL-92 Раздел. 5.2
На сервере Sql it is an option. Включение его в отстой.
Я не уверен в 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 забыл включить RDBMS в режим, чувствительный к регистру. (Чтобы быть справедливым, часть причины, по которой это катастрофа, - это то, что наши кодеры давно уже ошибочно полагались на чувствительность к регистру MySQL в UNIX.) Люди, которые написали установщик Windows MySQL, сделали это очень удобным и Windows-like, и было здорово продвигаться к тому, чтобы дать людям чекбокс, чтобы сказать: «Хочешь включить строгий режим и сделать MySQL более стандартным?» Но MySQL очень удобен в том, что он отличается от стандарта стандартным, а затем ухудшается, оборачиваясь и отличаясь от своего собственного стандарта де-факто на разных платформах. Я уверен, что в разных дистрибутивах Linux это может быть дополнительно усугублено, так как упаковщики для разных дистрибутивов, по-видимому, иногда использовали свои собственные настройки конфигурации MySQL.
Here еще один вопрос, который обсуждается, если чувствительность к регистру желательно в РСУБД.
Ключевые слова SQL не зависят от регистра.
Имена таблиц, столбцов и т. Д. Имеют чувствительность к регистру, зависящую от базы данных. Вероятно, вы должны предположить, что они чувствительны к регистру, если вы не знаете иначе (во многих базах данных их нет, а в именах таблиц MySQL есть случай SOMETIMES но большинство других имен нет).
Сравнение данных с использованием =,>, < и т. Д., Имеет осведомленность о случаях, которая зависит от настроек сортировки, которые используются в отдельной базе данных, таблице или столбце, о котором идет речь. Это нормально, однако, держать сопоставление достаточно последовательным в базе данных. У нас есть несколько столбцов, которые должны хранить значения, чувствительные к регистру; у них есть определенная сортировка.
Я нашел this blog post, чтобы быть очень полезным (я не являюсь автором).Суммируя (пожалуйста, прочитайте, хотя):
... разделителями идентификаторы чувствительны к регистру ("table_name" = "table_name"!), А не являющиеся в кавычки идентификаторы не являются, и преобразуются в верхний регистр (table_name => TABLE_NAME).
Он нашел DB2, Oracle и Interbase/Firebird являются 100% совместимый:
PostgreSQL ... каждый нижний регистр в кавычки идентификатор, вместо того, чтобы его верхний регистр. MySQL ... зависит от файловой системы. SQLite и SQL Server ... регистр имен таблиц и полей сохраняется при создании, но после этого они полностью игнорируются.
SQL92 specification указывает, что идентификаторы могут быть указаны или не кавычки. Если обе стороны не сортируются, то они всегда чувствительны к регистру, например. 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 и т. д.)
[Case Sensitive in Mysql с использованием select where Query] (http://stackoverflow.com/questions/14723825/case-sensitive-in-mysql-using-select-where-query) – 2013-02-08 04:59:27