Oracle не учитывать регистр
Поведение по умолчанию LIKE и других операторов сравнения и = т. Д. Чувствительно к регистру.
Можно ли сделать их без учета регистра?
Дружеское напоминание о том, что некоторые примеры поиска приведут к полному сканированию таблицы, даже если есть индекс для user_name.
Начиная с 10gR2, Oracle позволяет тонко настраивать поведение сравнения строк, устанавливая параметры NLS_COMP и NLS_SORT сессию:
Вы также можете создавать регистры без учета регистра:
Эта информация была взята из поисков без учета регистра Oracle . В статье упоминается, REGEXP_LIKE но, похоже, она работает и со старым добрым = .
В версиях старше 10gR2 это не может быть сделано, и обычный подход, если вам не нужен нечувствительный к акценту поиск, заключается просто UPPER() в столбце и поисковом выражении.
@SaqibAli Произвольные LIKE выражения (например, WHERE foo LIKE '%abc%' ) уже достаточно медленные, если их нельзя проиндексировать, я не думаю, что это определенно связано с чувствительностью к регистру.
Вы также можете установить их вне SQLPLUS, как в среде оболочки. Например, используя скрипт Perl DBD::Oracle , вы можете написать $ENV
эй ALTER SESSION только изменяет ваш локальный экземпляр исправления и означает ли это, как ваш текущий сеанс, то есть, если я закрою и снова открою, он будет сброшен. Есть ли способ, которым я могу видеть текущие значения, чтобы, если он сохранялся везде, я мог вернуться к исходным настройкам .
Существует 3 основных способа выполнения поиска без учета регистра в Oracle без использования полнотекстовых индексов.
В конечном итоге, какой метод вы выберете, зависит от ваших индивидуальных обстоятельств; Главное, что нужно помнить, это то, что для повышения производительности вы должны правильно индексировать для поиска без учета регистра.
Краткая сводка строковых функций
Как упоминалось ранее, PL/SQL предоставляет в распоряжение программиста широкий набор мощных, высокоуровневых строковых функций для получения информации о строках и модификации их содержимого. Следующий список дает представление об их возможностях и синтаксисе. За полной информацией о конкретных функциях обращайтесь к справочнику Oracle SQL Reference.
- ASCII(символ ) Возвращает числовой код (NUMBER) представления заданного символа в наборе символов базы данных.
- ASCIISTR(строка1) Получает строку в любом наборе символов и преобразует ее в строку ASCII-символов. Все символы, отсутствующие в кодировке ASCII, представляются в форме \XXXX, где XXXX — код символа в Юникоде.
- CHR(код)
Возвращает символ типа VARCHAR2 (длина 1), соответствующий заданному коду. Функция является обратной по отношению к функции ASCII. У нее имеется разновидность, удобная при работе с данными в национальных наборах символов:
Возвращает символ типа NVARCHAR2 из национального набора символов.
- COMPOSE(строка1)
Получает строку символов в формате Юникода и возвращает ее в нормализованном виде. Например, ненормализованное представление 'a\0303' определяет символ ' a ' с тильдой cверху (то есть a). Вызов COMPOSE('a\0303') возвращает значение ' \00E3' — шестнадцатеричный код символа a в Юникоде.
В Oracle9i Release 1 функция COMPOSE могла вызываться только из SQL-команд; в программах PL/SQL она использоваться не могла. Начиная с Oracle9i Release2, функция COMPOSE также может использоваться в выражениях PL/SQL.
- CONCAT(строка1, строка2)
Присоединяет строку2 в конец строки1. Аналогичного результата можно добиться при помощи выражения строка1 || строка2. Оператор || намного удобнее, поэтому функция CONCAT используется относительно редко. - CONVERT(строка1, набор_символов)
Преобразует строку из набора символов базы данных в заданный набор символов. При вызове также можно задать исходный набор символов:
CONVERT(строка1, конечный_набор, исходный_набор)
- DECOMPOSE(строка1)
Получает строку в Юникоде и возвращает строку, в которой все составные символы разложены на элементы. Функция является обратной по отношению к COMPOSE . Например, вызов DECOMPOSE ('a') возвращает строку ' a ~' (см. описание COMPOSE ).
Существует две разновидности этой функции:
- DECOMPOSE(строка1 CANONICAL)
Выполняет каноническую декомпозицию; полученный результат может быть восстановлен вызовом COMPOSE . Используется по умолчанию. - DECOMPOSE(строка1)
Декомпозиция выполняется в так называемом режиме совместимости. Восстановление вызовом COMPOSE может оказаться невозможным.
Функция DECOMPOSE , как и COMPOSE , не может напрямую вызываться в выражениях PL/SQL в Oracle9i Release 1; ее необходимо вызывать из инструкций SQL. Начиная с Oracle9i Release 2, это ограничение было снято.
Существует несколько разновидностей этой функции:
- INSTR(строка1, строка2, начальная_позиция)
Поиск строки2 в строке1 начинается с позиции, заданной последним параметром. По умолчанию поиск начинается с позиции 1, так что вызов INSTR(string1, string2, 1 ) эквивалентен вызову INSTR(string1, string2) . - INSTR(строка1, строка2, отрицательная_начальная_позиция)
Смещение начальной позиции задается не от начала, а от конца строки1. - INSTR(строка1, строка2, начальная_позиция, n )
Находит n-е вхождение строки2, начиная с заданной начальной позиции. - INSTR(строка1, строка2, отрицательная_начальная_позиция, n)
Находит n-е вхождение строки2, начиная с заданной начальной позиции от конца строки1.
Функция INSTR рассматривает строку как последовательность символов. Ее разновидности INSTRB, INSTR2 и INSTR4 рассматривают строку как последовательность байтов, кодовых единиц (code units) или кодовых индексов (code points) Юникода соответственно. Разновидность INSTRC рассматривает строку как последовательность полных символов Юникода. Например, строка 'a\0303' , которая представляет собой разложенный эквивалент '\00E3', или a , рассматривается как один символ. Напротив, функция INSTR рассматривает 'a\0303 ' как последовательность из двух символов.
- LEAST(строка1, строка2, . )
Получает одну или несколько строк и возвращает строку, которая оказалась бы первой (то есть наименьшей) при сортировке входных строк по возрастанию. Также см. описание функции GREATEST , обратной по отношению к LEAST . - LENGTH(строка1)
Возвращает количество символов в строке. Разновидности LENGTHB, LENGTH2 и LENGTH4 возвращают количество байтов, кодовых единиц (code units) или кодовых индексов (code points) Юникода соответственно. Разновидность LENGTHC возвращает количество полных символов Юникода, нормализованных по мере возможности (то есть с преобразованием 'a\0303 ' в '\00E3' ).
Функция LENGTH обычно не возвращает нуль. Вспомните, что Oracle рассматривает пустую строку ('') как NULL , поэтому вызов LENGTH ('') фактически эквивалентен попытке получить длину NULL ; ее результат тоже будет равен NULL . Единственное исключение встречается при применении LENGTH к типу CLOB . Тип CLOB может содержать 0 байт и при этом быть отличным от NULL . В этом единственном случае LENGTH возвращает 0.
- LOWER(строка1)
Преобразует все буквы заданной строки в нижний регистр. Функция является обратной по отношению к UPPER . Тип возвращаемого значения соответствует типу входных данных ( CHAR ,VARCHAR2, CLOB ). Также см. NLS_LOWER . - LPAD(строка1, итоговая_длина)
Возвращает значение строки1, дополненное слева пробелами до итоговой_длины . У функции существует следующая разновидность: - LPAD(строка1, итоговая_длина, заполнитель)
Присоединяет достаточное количество полных или частичных вхождений заполнителя, чтобы общая длина строки достигла заданной итоговой_длины . Например, вызов LPAD ( 'Merry Christmas!', 25, 'Ho! ') вернет результат ' Ho! Ho! HMerry Christmas!'.
- ?LTRIM(строка1)
Удаляет пробелы с левого края строки1. Также см. описания функций TRIM (стандарт ISO) и RTRIM . У функции существует следующая разновидность: - LTRIM(строка1, удаляемый_набор)
Удаляет любые символы, входящие в строку удаляемый_набор , от левого края строки1. - NCHR(код)
Возвращает символ типа NVARCHAR2 (длина 1) , соответствующий заданному коду. Функция CHR с условием USING NCHAR_CS реализует ту же функциональность, что и NCHR . - NLS_INITCAP (строка1)
Возвращает версию строки1, которая должна относиться к типу NVARCHAR2 или NCHAR , в которой первая буква каждого слова переводится в верхний регистр, а остальные буквы — в нижний. Функция возвращает значение типа VARCHAR2 . «Словом» считается последовательность символов, отделенная от остальных символов пробелом или символом, не являющимся буквенно-цифровым.
Вы можете задать порядок сортировки, влияющий на определение «первой буквы»:
- NLS_INITCAP(строка1, 'NLS_SORT=правило_сортировки')
В этой форме синтаксиса правило_сортировки представляет собой одно из допустимых названий правил сортировки, перечисленных в руководстве Oracle Database Globalization Support Guide, Appendix A, раздел «Linguistic Sorts».
Следующий пример показывает, чем функция INITCAP отличается от NLS_INITCAP :
В нидерландском языке последовательность символов « ? » рассматривается как один символ. Функция NLS_INITCAP распознает это обстоятельство при задании правила NLS_SORT и правильно преобразует символы слова « ?zer » («железо» по-нидерландски).
- NLS_LOWER(строка1) и NLS_LOWER(строка1, 'NLS_SORT=правило_сортировки ') Возвращает строку1, преобразованную в нижний регистр по правилам заданного языка. О том, как NLS_SORT может повлиять на результат преобразования, рассказано в описании функции NLS_INITCAP .
- NLS_UPPER(строка1) и NLS_UPPER(строка1, 'NLS_SORT=правило_сортировки') Возвращает строку1, преобразованную в верхний регистр по правилам заданного языка. О том, как NLS_SORT может повлиять на результат преобразования, рассказано в описании функции NLS_INITCAP .
- NLSSORT(строка1) и NLSSORT(строка1, 'NLS_SORT=правило_сортировки ') Возвращает строку байтов, которая может использоваться для сортировки строкового значения по правилам заданного языка. Строка возвращается в формате RAW . Например, сравнение двух строк по правилам французского языка выполняется так: IF NLSSORT(x, 'NLS_SORT=XFRENCH') > NLSSORT(y, 'NLS_SORT=XFRENCH') THEN. Если второй параметр не указан, функция использует порядок сортировки по умолчанию, назначенный для сеанса. Полный список правил приведен в руководстве Oracle Database Globalization Support Guide, Appendix A, раздел «Linguistic Sorts».
- REGEXP_COUNT, REGEXP_INSTR, REGEXP_LIKE, REGEXP_REPLACE, REGEXP_SUBSTR За описаниями этих функций, предназначенных для работы с регулярными выражениями, можно изучить эту статью.
- REPLACE(строка1, искомая_строка, замена) Возвращает строку, полученную в результате замены всех вхождений искомой_строки в строке1 строкой замена. Функция REPLACE может использоваться для замены всех вхождений определенной подстроки в одной инструкции.
- REPLACE(строка1, искомая_строка)
Возвращает строку, полученную в результате удаления всех вхождений искомой_строки из строки1. - RPAD(строка1, итоговая_длина)
Возвращает значение строки1, дополненное справа пробелами до итоговой_длины . У функции существует следующая разновидность: - RPAD(строка1, итоговая_длина, заполнитель)
Присоединяет достаточное количество полных или частичных вхождений заполнителя, чтобы общая длина строки достигла заданной итоговой_длины . Вызов RPAD('Merry Christmas!', 25, 'Ho! ') вернет результат 'Merry Christmas! Ho! Ho!'.
Функция RPAD дополняет строку справа, а парная ей функция LPAD — слева.
- RTRIM(строка1)
Удаляет пробелы с правого края строки1. Также см. описания функций TRIM (стандарт ISO) и LTRIM . У функции существует следующая разновидность: - RTRIM(строка1, удаляемый_набор)
Удаляет любые символы, входящие в строку удаляемый_набор , с правого края строки1. - SOUNDEX(строка1)
Возвращает строку с «фонетическим представлением» аргумента.
Пример:
При использовании функции SOUNDEX следует помнить несколько правил:
- Значение SOUNDEX всегда начинается с первой буквы входной строки.
- Возвращаемое значение генерируется только по первым пяти согласным в строке.
- Для вычисления цифровой части SOUNDEX используются только согласные. Все гласные в строке, кроме начальных, игнорируются.
- Функция SOUNDEX игнорирует регистр символов; для букв верхнего и нижнего регистра генерируются одинаковые значения SOUNDEX .
Функция SOUNDEX полезна для запросов, при которых точное написание значения в базе данных неизвестно или не может быть легко определенно.
Алгоритм SOUNDEX ориентирован на английский язык; в других языках он может работать плохо (или не работать вообще).
- SUBSTR(строка1, начальная_позиция, длина)
Возвращает подстроку из строки1, которая начинается с начальной_позиции и имеет заданную длину. Если количество символов до конца строки1 окажется меньше длины, возвращаются все символы от начальной позиции до конца строки. У функции существуют следующие разновидности: - SUBSTR(строка1, начальная_позиция)
Возвращает все символы от начальной_позиции до конца строки1. - SUBSTR(строка1, отрицательная_начальная_позиция, длина)
Начальная позиция подстроки отсчитывается от конца строки1. - SUBSTR(строка1, отрицательная_начальная_позиция)
Возвращает последние ABS( отрицательная_начальная_позиция ) строки.
Функция SUBSTR рассматривает строку как последовательность символов. Ее разновидности SUBSTRB, SUBSTR2 и SUBSTR4 рассматривают строку как последовательность байтов, кодовых единиц (code units) или кодовых индексов (code points) Юникода соответственно. Разновидность SUBSTRC рассматривает строку как последовательность полных символов Юникода. Например, строка 'a\0303' , которая представляет собой разложенный эквивалент '\00E3' , или a , рассматривается как один символ. Напротив, функция SUBSTR рассматривает 'a\0303' как последовательность из двух символов.
- TO_CHAR(национальные_символьные_данные)
Преобразует данные из национального набора символов в эквивалентное представление в наборе символов базы данных. Также см. TO_NCHAR .
Функция TO_CHAR также может использоваться для преобразования даты/ времени и чисел в удобочитаемую форму.
- TO_MULTI_BYTE(строка1)
Преобразует однобайтовые символы в их многобайтовые эквиваленты. В некоторых многобайтовых кодировках, и прежде всего UTF-8, может существовать несколько вариантов представления одного символа. Скажем, в UTF-8 представление буквы 'G' может содержать от 1 до 4 байт. Для перехода от однобайтового представления к многобайтовому используется функция TO_MULTI_BYTE . Данная функция является обратной по отношению к TO_SINGLE_BYTE . - TO_NCHAR(символы_в_наборе_базы_данных)
Преобразует данные из набора символов базы данных в эквивалентное представление в национальном наборе символов. Также см. TO_CHAR и TRANSLATE. USING.
Функция TO_NCHAR также может использоваться для преобразования даты/времени и чисел в удобочитаемую форму.
- TO_SINGLE_BYTE(строка1)
Преобразует многобайтовые символы в их однобайтовые эквиваленты. Функция является обратной по отношению к TO_MULTI_BYTE . - TRANSLATE(строка1, искомый_набор, набор_замены)
Заменяет в строке1 каждое вхождение символа из искомого_набора соответствующим символом набора_замены . Пример:
Если искомый_набор содержит больше символов, чем набор_замены , «лишние» символы, не имеющие соответствия в наборе_замены , не включаются в результат. Пример:
Буква « d » удалена, потому что она присутствует в искомом_наборе , но не имеет эквивалента в наборе_замены . Функция TRANSLATE заменяет отдельные символы, а функция REPLACE — целые строки.
- TRANSLATE(текст USING CHAR_CS) и TRANSLATE(текст USING NCHAR_CS)
Преобразует символьные данные в набор символов базы данных ( CHAR_CS ) или в национальный набор символов ( NCHAR_CS ). Выходным типом данных будет VARCHAR2 или NVARCHAR2 в зависимости от того, выполняется ли преобразование к набору символов базы данных или национальному набору символов соответственно.
Функция TRANSLATE. USING входит в число функций SQL по стандарту ISO. Начиная с Oracle9i Release 1, можно просто присвоить значение VARCHAR2 переменной типа NVARCHAR2 , и наоборот — система неявно выполнит нужное преобразование. Если же вы хотите выполнить преобразование явно, используйте функции TO_CHAR и TO_NCHAR для преобразования текста в набор символов базы данных и национальный набор символов соответственно. Oracle рекомендует пользоваться указанными функциями вместо TRANSLATE. USING , потому что они поддерживают более широкий набор входных типов данных.
- TRIM(FROM строка1)
Возвращает строку, полученную в результате удаления из строки1 всех начальных и конечных пробелов. У функции существуют следующие разновидности: - TRIM(LEADING FROM . )
Удаление только начальных пробелов. - TRIM(TRAILING FROM . )
Удаление только конечных пробелов. - TRIM(BOTH FROM . )
Удаление как начальных, так и конечных пробелов (используется по умолчанию). - TRIM (. удаляемый_символ FROM строка1)
Удаление вхождений одного удаляемого_символа на выбор программиста.
Функция TRIM была включена в Oracle8i для обеспечения более полной совместимости со стандартом ISO SQL. Она сочетает в себе функциональность LTRIM и RTRIM , но отличается от них тем, что TRIM позволяет задать только один удаляемый символ, тогда как при использовании LTRIM и RTRIM можно задать набор удаляемых символов.
- UNISTR(строка1)
Возвращает строку1, преобразованную в Юникод; таким образом, функция является обратной по отношению к ASCIISTR . Для представления непечатаемых символов во входной строке можно использовать запись \XXXX, где XXXX — кодовый индекс символа в Юникоде. Пример:
Функция предоставляет удобный доступ ко всему набору символов Юникода, в том числе и к тем, которые не могут вводиться непосредственно с клавиатуры.
Регистр символов часто играет важную роль в работе со строками. Например, может потребоваться сравнить две строки независимо от регистра. Выбор решения этой проблемы зависит как от версии базы данных, так и от области действия выполняемых операций.
3. Измените его на уровне сеанса.
Параметр NLS_SORT управляет последовательностью сопоставления для упорядочивания. и различные операторы сравнения, включая = и LIKE. Вы можете указать двоичную сортировку без учета регистра, изменив сеанс. Это будет означать, что каждый запрос, выполняемый в этом сеансе, будет выполнять параметры без учета регистра.
Существует много дополнительной информации о лингвистической сортировке и поиске строк если вы хотите указать другой язык, или выполнить поиск без учета акцента, используя BINARY_AI.
Вам также потребуется изменить параметр NLS_COMP. ; Цитировать:
Точные операторы и предложения запроса, которые подчиняются параметру NLS_SORT, зависят от значения параметра NLS_COMP. Если оператор или предложение не подчиняется значению NLS_SORT, как определено NLS_COMP, используется сопоставление BINARY.
Значение NLS_COMP по умолчанию - BINARY; но LINGUISTIC указывает, что Oracle следует обратить внимание на значение NLS_SORT:
При сравнении всех операций SQL в предложении WHERE и в блоках PL / SQL следует использовать лингвистическую сортировку, указанную в параметре NLS_SORT. Чтобы повысить производительность, вы также можете определить лингвистический индекс для столбца, для которого вы хотите лингвистические сравнения.
Итак, еще раз вам нужно изменить сеанс
Как указано в документации, вы можете создать лингвистический индекс для повышения производительности
Учитывает регистр в SQL. Я использовал MySQL и SQL Server, которые кажутся нечувствительными к регистру. Так всегда бывает? Определяет ли стандарт чувствительность к регистру?
Ключевые слова SQL нечувствительны к регистру ( SELECT , FROM , WHERE и т. Д.), Но часто пишутся заглавными буквами. Однако в некоторых настройках имена таблиц и столбцов чувствительны к регистру. MySQL имеет параметр конфигурации, позволяющий включать / отключать его. Обычно чувствительные к регистру имена таблиц и столбцов используются по умолчанию в Linux MySQL и без учета регистра используются по умолчанию в Windows, но теперь установщик спросил об этом во время установки. Для MSSQL это функция настройки сортировки базы данных.
Некоторые системы (например, PostgreSQL) чувствительны к регистру в именах таблиц и столбцов, но пытаются скрыть это с помощью строчных или прописных букв всех имен, прежде чем искать их. В этих системах вам нужно будет заключить имя таблицы в «двойные кавычки», чтобы убедиться, что точное имя, которое вы ввели, ищется.
"но часто пишутся заглавными буквами" Я не согласен, это просто предпочтение, я всегда видел прямо противоположное
Например, если сервер MS Sql установлен с использованием сортировки с учетом регистра, то имена таблиц, столбцов и переменных становятся чувствительными к регистру, даже если база данных имеет сортировку без учета регистра.
- В руководствах Oracle есть все примеры SQL с ключевыми словами (SELECT, FROM, WHERE и т.д.), написанными в верхнем регистре, но имена таблиц и столбцов в нижнем регистре.
Хммм, это все еще верно для mysql? Я думал, что у меня установлен mysql по умолчанию, и он нечувствителен к регистру имен столбцов.
Это не строго язык SQL, но в SQL Server, если сортировка вашей базы данных чувствительна к регистру, тогда все имена таблиц чувствительны к регистру.
Я не уверен насчет MySql.
В MySql нечувствительность к регистру - это опция, которую вы можете включать и выключать. Эта нечувствительность не работает так, как можно было бы предположить в Linux, если файловая система чувствительна к регистру (по умолчанию). Вы должны сделать файловую систему без учета регистра в Linux, чтобы нечувствительность к регистру mysql работала так же, как и в Windows (= правильно). Особенно включение / выключение после некоторой работы в другом режиме может иметь плохие последствия.
В спецификации SQL92 говорится, что идентификаторы могут быть заключены в кавычки или не заключены в кавычки. . Если обе стороны не заключены в кавычки, они всегда нечувствительны к регистру, например table_name == TAble_nAmE .
Однако цитируемые идентификаторы чувствительны к регистру, например "table_name" != "TAble_naME" . Также на основе спецификации, если вы хотите сравнить идентификаторы без кавычек с идентификаторами в кавычках, то идентификаторы без кавычек и идентификаторы в кавычках могут считаться одинаковыми, если символы без кавычек имеют верхний регистр, например TABLE_NAME == "TABLE_NAME" , но TABLE_NAME != "table_name" или TABLE_NAME != "TAble_NaMe" .
Вот соответствующая часть спецификации (раздел 5.2.13):
Обратите внимание, что, как и в случае с другими частями стандарта SQL, не все базы данных полностью следуют этому разделу. PostgreSQL, например, хранит все идентификаторы без кавычек в нижнем регистре, а не в верхнем, поэтому table_name == "table_name" (что является полной противоположностью стандарту). Кроме того, некоторые базы данных все время нечувствительны к регистру или чувствительность к регистру зависит от некоторых настроек в БД или от некоторых свойств системы, обычно от того, чувствительна ли файловая система к регистру или нет.
Обратите внимание, что некоторые инструменты базы данных могут отправлять идентификаторы, цитируемые все время, поэтому в тех случаях, когда вы смешиваете запросы, созданные каким-либо инструментом (например, запрос CREATE TABLE, сгенерированный Liquibase или другим инструментом миграции БД), с запросами, сделанными вручную (например, простой выбор JDBC в вашем приложении) вы должны убедиться, что случаи согласованы, особенно в базах данных, где цитируемые и некотируемые идентификаторы различаются (DB2, PostgreSQL и т. д.)
Идентификаторы и зарезервированные слова не должны быть чувствительны к регистру, хотя многие следуют соглашению использовать заглавные буквы для зарезервированных слов и регистр Паскаля для идентификаторов.
Насколько я понимаю, стандарт SQL требует нечувствительности к регистру. Однако я не верю, что какие-либо базы данных полностью соответствуют стандарту.
MySQL имеет параметр конфигурации как часть своего «строгого режима» (набор с несколькими настройками, которые делают MySQL более совместимым со стандартами) для чувствительных к регистру или нечувствительных к регистру имен таблиц. Независимо от этого параметра, имена столбцов по-прежнему нечувствительны к регистру, хотя я думаю, что это влияет на то, как отображаются имена столбцов. Я считаю, что этот параметр является общесистемным для всех баз данных в экземпляре СУБД, хотя сегодня я занимаюсь исследованием, чтобы подтвердить это (и надеюсь, что ответ отрицательный).
Мне нравится, как Oracle справляется с этим намного лучше. В прямом SQL такие идентификаторы, как имена таблиц и столбцов, не чувствительны к регистру. Однако, если по какой-то причине вы действительно хотите получить явный регистр, вы можете заключить идентификатор в двойные кавычки (которые сильно отличаются в Oracle SQL от одинарных кавычек, используемых для заключения строковых данных). Так:
Будет запрашивать fieldname из tablename , но
Будет запрашивать fieldName из tableName .
Я почти уверен, что вы даже можете использовать этот механизм для вставки пробелов или других нестандартных символов в идентификатор.
В этой ситуации, если по какой-то причине вы сочли желательными имена таблиц и столбцов с явно указанным регистром, они были доступны вам, но я бы настоятельно предостерегал от этого.
Мое соглашение, когда я ежедневно использовал Oracle, заключалось в том, что в коде я помещал все ключевые слова Oracle SQL в верхний регистр, а все идентификаторы в нижний регистр. В документации я бы поставил все имена таблиц и столбцов в верхнем регистре. Это было очень удобно и читабельно (хотя иногда было больно набирать так много заглавных букв в коде - я уверен, что мог бы найти здесь функцию редактора, которая могла бы помочь).
На мой взгляд, MySQL особенно плох из-за различий в этом на разных платформах. Нам необходимо иметь возможность выгружать базы данных в Windows и загружать их в UNIX, и это будет катастрофой, если установщик в Windows забудет перевести РСУБД в режим с учетом регистра. (Честно говоря, одна из причин, по которой это катастрофа, заключается в том, что наши программисты давно приняли плохое решение полагаться на чувствительность к регистру MySQL в UNIX.) Люди, написавшие установщик Windows MySQL, сделали его действительно удобным и Подобно Windows, и было здорово перейти к тому, чтобы дать людям флажок, который мог бы сказать: «Хотите ли вы включить строгий режим и сделать MySQL более совместимым со стандартами?» Но для MySQL очень удобно так существенно отличаться от стандарта, а затем усугублять ситуацию, отклоняясь от своего собственного стандарта де-факто на разных платформах. Я уверен, что в разных дистрибутивах Linux это может еще больше усугубиться, поскольку упаковщики для разных дистрибутивов, вероятно, иногда включали свои собственные предпочтительные параметры конфигурации MySQL.
Здесь еще один вопрос SO, который обсуждается, если -чувствительность желательна в РСУБД.
Я нашел этот пост в блоге очень полезным (я не автор). Подводя итог (пожалуйста, прочтите):
. идентификаторы с разделителями чувствительны к регистру ("table_name"! = "Table_Name"), а идентификаторы без кавычек - нет, и преобразуются в верхний регистр (table_name => TABLE_NAME).
Он обнаружил, что DB2, Oracle и Interbase / Firebird на 100% совместимы:
PostgreSQL . вводит каждый идентификатор без кавычек в нижний регистр, а не в верхний. MySQL . зависит от файловой системы. SQLite и SQL Server . регистр имен таблиц и полей сохраняется при создании, но впоследствии полностью игнорируется.
Я не думаю, что SQL Server чувствителен к регистру, по крайней мере, не по умолчанию.
Когда я запрашиваю вручную через Management Studio, я все время путаю кейс, и он с радостью его принимает:
Ключевые слова SQL сами по себе нечувствительны к регистру.
Имена таблиц, столбцов и т. Д. Имеют чувствительность к регистру, зависящую от базы данных - вы, вероятно, должны предположить, что они чувствительны к регистру, если вы не знаете иначе (во многих базах данных это не так; в именах таблиц MySQL НЕКОТОРЫЕ чувствительны к регистру, но большинство других имена нет).
При сравнении данных с использованием =,>, 2
Получите лучшее из обоих миров
В наши дни вы можете просто писать все свои sql-операторы в нижнем регистре, и если вам когда-нибудь понадобится его отформатировать, просто установите плагин, который сделает это за вас. Это применимо только в том случае, если в вашем редакторе кода есть эти плагины. VSCode имеет множество расширений, которые могут это сделать.
Нет. MySQL не чувствителен к регистру, как и стандарт SQL. Это обычная практика - писать команды в верхнем регистре.
Теперь, если вы говорите об именах таблиц / столбцов, то да, но не о самих командах.
Но не то же самое, что
В большинстве СУБД имена таблиц также не чувствительны к регистру. По крайней мере, не по умолчанию. MySQL - наиболее заметное исключение из этого правила.
Символьная функция получает в качестве параметра одно или несколько символьных значений и возвращает символьное и числовое значение. Если символьная функция возвращает символьное значение, оно всегда имеет тип VARCHAR2 (переменная длина) — кроме функций UPPER и LOWER . Эти функции преобразуют заданную строку к верхнему или нижнему регистру соответственно и возвращают значение фиксированной длины типа CHAR , если переданные в аргументах строки имели тип CHAR .
3. Измените его на уровне сеанса.
Параметр NLS_SORT управляет последовательностью сортировки для упорядочения и различных операторов сравнения, в том числе = и LIKE. Вы можете указать двоичную сортировку без учета регистра, изменив сеанс. Это будет означать, что каждый запрос, выполненный в этом сеансе, будет выполнять параметры без учета регистра.
Существует много дополнительной информации о лингвистической сортировке и поиске строк, если вы хотите указать другой язык или выполнить нечувствительный к акценту поиск с помощью BINARY_AI.
Вам также необходимо изменить параметр NLS_COMP ; Цитировать:
Точные операторы и предложения запроса, которые подчиняются параметру NLS_SORT, зависят от значения параметра NLS_COMP. Если оператор или предложение не подчиняются значению NLS_SORT, как определено NLS_COMP, используемое сопоставление - BINARY.
Значением по умолчанию NLS_COMP является BINARY; но LINGUISTIC указывает, что Oracle должен обратить внимание на значение NLS_SORT:
Для сравнения всех операций SQL в предложении WHERE и в блоках PL / SQL следует использовать лингвистическую сортировку, указанную в параметре NLS_SORT. Чтобы повысить производительность, вы также можете определить лингвистический индекс для столбца, для которого вы хотите лингвистические сравнения.
Итак, еще раз, вам нужно изменить сеанс
Как отмечено в документации, вы можете создать лингвистический индекс для повышения производительности.
Поведение по умолчанию для LIKE и других операторов сравнения, = и т. Д. Учитывает регистр.
Можно ли сделать их нечувствительными к регистру?
Начиная с 10gR2, Oracle позволяет точно настраивать поведение сравнения строк, задавая NLS_COMP и NLS_SORT параметры сеанса:
Вы также можете создавать индексы без учета регистра:
Эта информация была взята из поисковых запросов Oracle без учета регистра. В статье упоминается REGEXP_LIKE , но, похоже, он работает и со старым-добрым = .
В версиях старше 10gR2 это невозможно сделать, и обычный подход, если вам не нужен нечувствительный к акценту поиск, состоит в том, чтобы просто UPPER() и столбец, и выражение поиска .
Есть 3 основных способа выполнить поиск без учета регистра в Oracle без использования полнотекстовых индексов.
В конечном счете, какой метод вы выберете, зависит от ваших индивидуальных обстоятельств; главное помнить, что для повышения производительности вы должны правильно индексировать поиск без учета регистра.
Преобразование первого символа к верхнему регистру
Кроме функций UPPER и LOWER , для преобразования регистра символов используется функция INITCAP . Она преобразует первую букву каждого слова в строке к верхнему регистру, а все остальные буквы — к нижнему регистру. Например, следующий фрагмент:
выводит следующий результат:
Идея использовать INITCAP для форматирования имен выглядит заманчиво, и все будет хорошо, пока вы не столкнетесь с особым случаем:
Правильное написание фамилии — «McWilliams», а не «Mcwilliams». Помните, что функция INITCAP временами удобна, но она выдает неверный результат для имен и слов, которые содержат более одной буквы в верхнем регистре.
2. Используйте регулярные выражения.
От Oracle 10g и REGEXP_LIKE() более доступна. Вы можете указать _match_parameter_ 'i' , чтобы выполнить поиск без учета регистра.
Чтобы использовать это как оператор равенства, вы должны указать начало и конец строки, которая обозначается в каратах и знаком доллара.
Чтобы выполнить эквивалент LIKE, их можно удалить.
Будьте осторожны с этим, поскольку ваша строка может содержать символы, которые будут по-разному интерпретироваться механизмом регулярных выражений.
Эта SQL Fiddle показывает тот же пример вывода, за исключением использования REGEXP_LIKE ().
Сравнение без учета регистра символов
Начиная с Oracle10g Release 2, появилась возможность использования параметров инициализации NLS_COMP и NLS_SORT для включения режима сравнения без учета регистра. Задайте параметру NLS_COMP значение LINGUISTIC ; тем самым вы прикажете Oracle использовать NLS_SORT для сравнений строк. Затем задайте параметру NLS_SORT значение, соответствующее сравнению без учета регистра — например, BINARY_CI или XWEST_EUROPEAN_CI . (Суффикс _CI означает «Case Insensitivity», то есть «Без учета регистра».) Приведенный далее простой пример показывает, какие проблемы решаются при помощи NLS_COMP . Требуется взять список имен и определить, какое из них должно стоять на первом месте:
В моей системе этот вызов LEAST возвращает строку ' JONATHAN '. Дело в том, что в порядке сортировки символы верхнего регистра предшествуют символам нижнего регистра. По умолчанию параметру NLS_COMP задается значение BINARY , при котором результат строковых сравнений, выполняемых такими функциями, как LEAST , определяется кодами символов.
Возможно, вы предпочитаете, чтобы функция LEAST игнорировала регистр символов и возвращала 'jon' вместо ' JONATHAN '. Измените значение NLS_COMP , чтобы при сортировке учитывалось значение NLS_SORT :
Теперь необходимо изменить NLS_SORT с указанием нужных правил сортировки.
По умолчанию переменная NLS_SORT часто равна BINARY , но значение может быть и другим в зависимости от конфигурации системы. В нашем примере будет использоваться сортировка BINARY_CI :
Попробуем снова вызвать LEAST :
На этот раз будет получен результат ' jon '. Пример кажется простым, но добиться такого результата без только что описанной сортировки по правилам языка будет нелегко.
Действие языковой сортировки распространяется не только на функции, но и на простые сравнения строк. Пример:
При указанных значениях параметров NLS_COMP и NLS_SORT выражение ' Jonathan ' = ' JONATHAN ' в этом примере равно TRUE .
Параметры NLS_COMP и NLS_SORT влияют на все операции со строками. Они продолжают действовать вплоть до их явного изменения или до завершения сеанса.
Oracle также поддерживает режим сортировки без учета диакритических знаков; чтобы включить его, присоедините к имени правила сортировки суффикс _AI (вместо _CI ).
За полным списком правил языковой сортировки обращайтесь к документации Oracle Database Globalization Support Guide. В этом руководстве также подробно объясняется действие параметров NLS_COMP и NLS_SORT .
2. Используйте регулярные выражения.
Начиная с Oracle 10g и далее REGEXP_LIKE() доступен. Вы можете указать _match_parameter_ 'i' , чтобы выполнять поиск без учета регистра.
Чтобы использовать это как оператор равенства, вы должны указать начало и конец строки, которые обозначаются каратом и знаком доллара.
Чтобы выполнить аналог LIKE, их можно удалить.
Будьте осторожны с этим, поскольку ваша строка может содержать символы, которые будут по-разному интерпретироваться обработчиком регулярных выражений.
Этот скрипт SQL показывает тот же пример вывода, за исключением использования REGEXP_LIKE ().
Преобразование строки к верхнему или нижнему регистру
Для решения проблем с регистром символов можно воспользоваться встроенной функцией UPPER или LOWER . Эти функции преобразуют всю строку за одну операцию. Пример:
В этом примере обе строки обрабатываются функцией LOWER , так что в итоговом сравнении участвуют строки ' andrew sears' и ' andrew sears '.
1. Обсудите ваш столбец и строку одинаково.
Вы можете заставить все ваши данные быть в одном и том же случае с помощью UPPER() или LOWER() :
Если column_1 индекс не включен upper(column_1) или lower(column_1) , в зависимости от ситуации, это может привести к полному сканированию таблицы. Чтобы избежать этого, вы можете создать индекс на основе функций .
Если вы используете LIKE, вы должны объединить % вокруг искомой строки.
Эта скрипта SQL демонстрирует, что происходит во всех этих запросах. Обратите внимание на планы объяснения, которые указывают, когда индекс используется, а когда нет.
1. Сохраняйте столбец и строку одинаково.
Вы можете заставить все ваши данные быть одинаковыми, используя UPPER() или LOWER() :
Если column_1 не проиндексирован на upper(column_1) или lower(column_1) , в зависимости от ситуации, это может вызвать полное сканирование таблицы. Чтобы избежать этого, вы можете создать индекс на основе функций .
Если вы используете LIKE, вам нужно объединить % вокруг искомой строки.
Этот скрипт SQL демонстрирует, что происходит во всех этих запросах. Обратите внимание на планы объяснения, которые указывают, когда индекс используется, а когда нет.
1. Обсудите ваш столбец и строку одинаково.
Вы можете заставить все ваши данные быть в одном и том же случае с помощью UPPER() или LOWER() :
Если column_1 индекс не включен upper(column_1) или lower(column_1) , в зависимости от ситуации, это может привести к полному сканированию таблицы. Чтобы избежать этого, вы можете создать индекс на основе функций .
Если вы используете LIKE, вы должны объединить % вокруг искомой строки.
Эта скрипта SQL демонстрирует, что происходит во всех этих запросах. Обратите внимание на планы объяснения, которые указывают, когда индекс используется, а когда нет.
Регистр символов и индексы
При работе со строками часто возникает необходимость в поиске и сравнении без учета регистра символов. Но если вы реализуете описанный здесь прием, вдруг выясняется, что ваше приложение перестает использовать индексы и начинает работать слишком медленно. Будьте внимательны, чтобы ваши действия не повредили использованию индексов в SQL. Для наглядности рассмотрим пример с демонстрационной таблицей hr.employees . Таблица employees использует индекс emp_name_ix для столбцов last_name , first_name . Мой код включает следующую команду SQL:
Изначально код использует индекс emp_name_ix , но когда я задаю параметры NLS_COMP=LINGUISTIC и NLS_SORT=BINARY_CI , чтобы включить поиск без учета регистра, индекс перестает использоваться, и операции выполняются с полным просмотром таблицы — со всеми вытекающими последствиями! Одно из возможных решений заключается в использовании индекса на базе функции, игнорирующего регистр символов:
Теперь при выполнении запросов без учета регистра символов используется индекс без учета регистра, а быстродействие программы остается на высоком уровне.
Читайте также: