Выполнение поиска без учета регистра в базе данных Oracle - PullRequest
5 голосов
/ 19 сентября 2011

Мой фон базы данных находится на стороне MS SQL Server, где при сравнении текста в индексах и ограничениях регистр не учитывается (по крайней мере, по умолчанию).Поэтому, если у вас есть значение «abc», присвоенное уникальному столбцу, вы не можете сохранить второе значение «ABC», и если вы ищете «ABC», SQL Server найдет «abc».

С вещами Oracleотличаются, поэтому даже с уникальным индексом в текстовом столбце вы можете хранить там и «abc», и «ABC», и если вы будете искать «AbC», вы не получите никакого результата.

AFAIK доOracle 10gR2 не было никакого способа обойти это, теперь можно установить нечувствительное сравнение для каждой сессии, что, IMHO, не очень хорошее решение, потому что все зависит от дисциплины программистов.

Но что хуже всего при поиске с учетом регистра, так этокоторый переписывает все поиски как UPPER(some_column)=UPPER(some_text) (и это то, что рекомендуют многие дискуссионные потоки), заканчивает сканирование таблицы, даже если для some_column есть индекс.Снижение производительности является катастрофическим: я только что проверил простой поиск в таблице с полмиллиона строк, и поиск с вызовом функции UPPER занял в 20 раз больше времени, чем поиск с использованием только идентификатора столбца, что подтверждает, что индекс не используется при выполнении функциипоиск на основе.

Действительно ли так, что наиболее стандартным методом для поиска без учета регистра в базе данных Oracle является применение функций UPPER / LOWER к элементам поиска, несмотря на плохую производительность?Или есть более элегантные способы решения этой проблемы?

Ответы [ 2 ]

7 голосов
/ 19 сентября 2011

Да, использование UPPER(some_column)=UPPER(some_text) действительно лучший способ, но вы можете создать индекс для UPPER(some_column). Это должно облегчить проблему.

0 голосов
/ 19 сентября 2011

Я бы сказал, создайте «чистые» поля, основанные на бизнес-логике вашей компании, для очистки этих полей (например, название или адрес компании будет иметь удивительное количество логики очистки вокруг слов мебели, правил usps и т. Д., А неупомянуть сторонние процедуры очистки, если они используются).

Итак, для важных полей поиска оставьте ОБА чистую (нечистую) и чистую версии.Если ваша логика очистки значительно меняется с течением времени, вы можете вернуться и выполнить повторные операции на основе необработанных значений.Ваш поиск (при условии, что вы не используете механизм нечеткой логики, такой как Oracle Text или Lucene), достигнет чистых значений.

Для всех других полей (которые не заслуживают отдельных чистых версий) я обычно выполняю минимумуровень очистки.Использование заглавных букв, обрезка, управление полосами, сокращение нескольких пробелов до 1 пробела и т. Д. - все это является частью набора базовых процедур очистки.Обычно это делается до загрузки данных (в программах построения данных).

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...