Поиск, нечувствительный к регистру

← →
Байрам (2005-12-07 21:39) [0]

hi all
Использую в качестве поиска по базе like
Как оптимальней, и какие еще кроме Locate есть способы, сделать поиск нечуствительным к регистру букв?
for example слово в базе: Пример.
Нужно чтобы это слово находилось и при вводе: пример, пРИМЕР, ПрИмЕр...

← →
Sergey Masloff (2005-12-07 21:57) [1]

Нужно в базе хранить в одном регистре.

← →
Reindeer Moss Eater © (2005-12-07 22:00) [2]

>Как оптимальней
Оптимальнее если используется индекс

и какие еще кроме Locate есть способы, сделать поиск нечуствительным к регистру букв?

while not eof do
begin
...
Next;
end;

← →
DrPass © (2005-12-07 23:36) [3]

LIKE тоже нечувствителен к регистру, с тех пор, как придумали функцию UPPER (и LOWER). Но индексы при этом не используются, конечно. Впрочем, можно приводить все к одному регистру при записи в БД.

> Reindeer Moss Eater © (07.12.05 22:00) [2]
while not eof do
begin
...
Next;
end;

Рано автору еще такими настоящими хакерскими методами пользоваться... пусть что-нибудь ламерское попробует - LIKE, Locate...

← →
Anatoly Podgoretsky © (2005-12-07 23:48) [4]

Так автор и разныицы между выборкой и поиском не совсем понимает.

← →
Сафаров © (2005-12-08 00:15) [5]

о какой вы оптимальности говорите? о теоретической?
MS SQL
Выборка
select * from table where Upper(name) like upper(:name)
в таблице сгенерил 1 млн. записей. Поле name varchar(20)
время выборки - 10 c.
с использованием индексов - 9 c. (как кластерных, так и некластерных). Правда индексировать такие поля MS не рекомендует. О чем можно убедиться как раз на таком примере

← →
Anatoly Podgoretsky © (2005-12-08 00:20) [6]

Сафаров © (08.12.05 00:15) [5]
Для MS SQL проще, если соответствующий Collatting
select * from table where name like :name
Попробуй и сравни время.

А индекс какой ты имеешь в виду?

← →
Сафаров © (2005-12-08 00:26) [7]

MS не рекомендует использовать индексы в полях, превышающих по длине 10 байт. Как раз сегдня пытался настроить подобный запрос на скорость. Перебирал подобные варианты с индексами и без них. Разницы в скорости практически не почуствовал. Выборка где-то 100 строк из миллионой таблицы. С полнотекстовыми еше не разбирался

← →
Anatoly Podgoretsky © (2005-12-08 00:32) [8]

Сафаров © (08.12.05 00:26) [7]
Я вообщето про индекс с выражением, типа UPPER(fld), иначе о каком индексе вообще можно говорить в подобном случае.
Попробуй проверить предложеное по твоей базе с индексом и без. Естественно, что like не должен быть %value% и еще кроме like есть containing, тоже оптимальнее в некоторых случаях.

← →
Сафаров © (2005-12-08 00:39) [9]

Заказчика интересует как-раз выборка на вхождение.
Запрос: "по-моему назывался он как-то так". A на счет containing - попробую, спасибо за подсказку.

← →
Сафаров © (2005-12-08 00:40) [10]

и еще на счет "Нужно в базе хранить в одном регистре". Это решает заказчик

← →
Anatoly Podgoretsky © (2005-12-08 00:51) [11]

Хранить в одном регистре это очень жестоко. Лучше использовать сервер не чувствительный к регистру или обходными путями приводить к одному регистру, что очень неэффективно и не позволяет задействовать индексы.

← →
Reindeer Moss Eater © (2005-12-08 00:54) [12]

Если с индексом не оптимально, то оптимально без индекса.
Если 9 секунд не оптимально, то 10 секунд это оптимально.

Получается так.

← →
Anatoly Podgoretsky © (2005-12-08 00:54) [13]

CONTAINS
( { column | * } , "< contains_search_condition >"
)

← →
Sergey_Masloff (2005-12-08 09:27) [14]

Сафаров © (08.12.05 00:40) [10]
>и еще на счет "Нужно в базе хранить в одном регистре". Это решает >заказчик
Ну если у Вас заказчик решает как хранить в базе то я молчу. У меня заказчик решает только как это должно отображаться через интерфейс. А записей у меня поболее на 2 порядка чем в вашем тестовом примере ;-)
Поиск 10 с. просто неприемлем. У меня эвристический быстрее выполняется ;-) Ну когда вместо Иванов Иван Иванович задали Ивнов Иваи Иванович

Anatoly Podgoretsky © (08.12.05 00:51) [11]
>Хранить в одном регистре это очень жестоко.
Мы храним вроде никто не жалуется. 10 лет уже, пользователей много тысяч пока никто ничего не заметил ;-)

← →
Anatoly Podgoretsky © (2005-12-08 11:30) [15]

Sergey_Masloff (08.12.05 09:27) [14]
Я полагаю, что вы храните в двух полях, так? Одно для поиска, а второе для отображения.

← →
Sergey_Masloff (2005-12-08 15:24) [16]

Anatoly Podgoretsky © (08.12.05 11:30) [15]
>Я полагаю, что вы храните в двух полях, так? Одно для поиска, а второе >для отображения.
На самом деле совсем недавно так сделали. А так обходились InitCap() и InitCapFirst() из названий понятно что делают функции.

Sergey_Masloff (08.12.05 15:24) [16]
То есть насиловали пользователя, не позволяя хранить как AbcDef
или же использовали это как UDF

← →
Sergey_Masloff (2005-12-08 16:25) [18]

← →
Байрам (2005-12-08 19:26) [19]

Действительно мне была нужна выборка записей.

Добил я таки функцию upper , чтобы она заработала на моей базе.

Всем спасибо.

Sergey_Masloff (08.12.05 16:25) [18]
Это хорошо когда можно, но ведь так не всегда.

← →
Дмитрий Белькевич (2005-12-09 03:03) [21]

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

Поиск, нечувствительный к регистру Найти похожие ветки