Регистрозависимый поиск в SQL
SQL запрос, казалось бы, написан абсолютно ясно и прозрачно, но результат не тот, который ожидаем. О маленьких деталях в работе с большими символами пойдёт речь.
В рамках работы над проектом одна из задач заключалась в том, что из огромного массива необходимо было выбрать карты с определённым кодом. Коды карт могут иметь значения как символы типа ‘+’или ‘0’, так и символы — буквы алфавита, в том числе строчные и прописные. При работе с кодами карт в виде цифр и спецсимволов проблем не возникло, НО. В процессе работы с кодами карт в виде символов — букв алфавита разного регистра мы столкнулись с проблемой. Наш простой запрос выдавал нам все данные, независимо от регистра:
итог:
Кто и почему не понимает нас?
Оказалось, что на нашем сервере установлены параметры сортировки без учёта регистра.
Я нашла несколько способов решения и хочу поделиться с вами:
Первый способ.
Использование функции ASCII, которая возвращает числовой код крайнего левого символа строкового выражения, являющегося аргументом функции.
Синтаксис функции ASCII( single_character) .
Например, if ASCII(code)=ASCII(‘m’) is TRUE – значение нашего аргумента строчное;
Второй способ.
Мы можем написать запрос сравнения с учетом регистра изменив регистр нашего аргумента и используя collate:
Третий способ.
Функция Unicode, которая возвращает юникод первого значения.
Синтаксис функции: unicode (<строковое выражение>).
Возможны варианты использования значений юникодов:
Мы можем создать таблицу- справочник юникодов наших кодов продуктов;
Получим значения юникодов наших аргументов:
либо вычислить юникод изменив регистр нашего аргумента и сравнить с юникодом нашего аргумента;
В результате получим информацию о регистре значения кода для дальнейшего анализа и использования в запросе.
ещё один путь- сразу в коде сравнивать вычисляемое значение с уже известным нам числовым, если их немного и это не трудоёмко.
Именно этот вариант я применила в своей работе, т.к. количество необходимых символов для сравнения было невелико.
Думаю, что предпочтительный вариант каждый определит для себя исходя из специфики задачи и, не исключено, что найдутся другие пути решения, ведь SQL –язык многогранный. Надеюсь, мой опыт будет полезен в работе.