Ускорение запроса LIKE '*xxx*'

[VVitafresh]

Делаю запрос к базе Access

Код: Выделить всё

Select * from table1 where cod like '*codpart*'

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

[alibek]

Первую звездочку убери.

[VVitafresh]

Хм. Быстрее то оно конечно будет, только не выведет все позиции. Мне нужно, чтобы по части кода выводился полный перечень позиций, содержащих такой код. Например, пользователь вводит: 256401. В результат должны попасть: PR 256401, 256401 ZA, PE256401ZA и т.п.
В такой интрерпретации запрос не ускорить

[Andrey Fedorov]

Хм. Быстрее то оно конечно будет, только не выведет все позиции. Мне нужно, чтобы по части кода выводился полный перечень позиций, содержащих такой код. Например, пользователь вводит: 256401. В результат должны попасть: PR 256401, 256401ZA, PE256401ZA и т.п.
В такой интрерпретации запрос не ускорить

Нет.

Можно сделать отдельным поле в который заносить только цифирь, ну и если юзер вводит циферки - ищем по нему... Без первой звездочки.

[alibek]

Хм. Быстрее то оно конечно будет, только не выведет все позиции.

Ну на нет и суда нет.
При запросах типа LIKE *text* индексы не используются, осуществляется полный скан таблицы.

[GSerg]

А при запросах типа WHERE InStr(cod, 'codpart')<>0 скан осуществляется?

[VVitafresh]

В общем дело ясное... Ну нельзя -- значит нельзя
Насчет полного скана я в общем-то знал, но думал может есть выход из ситуации.

[alibek]

А при запросах типа WHERE InStr(cod, 'codpart')<>0 скан осуществляется?

Боюсь, что да. К тому же, а разве INSTR это ANSI-шная функция? Она вроде бы только Jet-провайдером поддерживается.

[Andrey Fedorov]

Насчет полного скана я в общем-то знал, но думал может есть выход из ситуации.

И я тебе его сказал. Выше.

[VVitafresh]

Боюсь, что да. К тому же, а разве INSTR это ANSI-шная функция? Она вроде бы только Jet-провайдером поддерживается.

Instr на всякий случай попробую, вдруг быстрее будет. То что поддерживает только JET меня не пугает база у меня в Access и перехода на MS SQL не планируется.

И я тебе его сказал. Выше.

Спасибо! Я твой вариант прекрасно понял, но он не подходит. Цифры я написал лишь для примера. Смысл заключается в облегчении поиска пользователю, когда известна лишь часть кода (требование заказчика программы). При этом какая часть будет вводиться заранее не известно.

[Andrey Fedorov]

Смысл заключается в облегчении поиска пользователю, когда известна лишь часть кода (требование заказчика программы). При этом какая часть будет вводиться заранее не известно.

Тогда никак иначе.

Кстати, а у Вас юзеры вводят части кода разными кодировками?
А то мне приходилось и этим озадачиваться...

[alibek]

А сколько записей должно быть возвращено в результате запроса? (в среднем)

[VVitafresh]

Кстати, а у Вас юзеры вводят части кода разными кодировками?

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

А сколько записей должно быть возвращено в результате запроса? (в среднем)

Не очень много. До нескольких десятков.
А это на что-то влияет?

[alibek]

И что, из 500 тысяч записей будет возвращено несколько десятков только по фильтру code? Неужели нет дополнительных критериев группировки?
Мне в это трудно поверить.
Либо это какой-то уникальный ключ (и тогда непонятно, зачем LIKE), либо есть и другие поля, по которым можно предварительно ограничить набор данных.

[VVitafresh]

Уникальный индекс у меня это код товара, его категория и код поставщика. Поиск осуществляется по коду товара, из которого удалены пробелы и др. "лишние" символы, от чего это поле перестает быт уникальным, но облегчает поиск, т.к. не нужно запоминать в каком месте стоит пробел, в каком тире и т.п.
Разные поставщики могут кодировать свой товар по-разному, но какая-то часть кода у них обязательно совпадает. И смысл такого поиска в том, чтобы вывести товар по ВСЕМ поставщикам (показать "широту выбора").
Пример: ASK 10256321, 102 563 21, AS-102563-21 у разных поставщиков может означать одно и то же.
И нужно эти товары вывести даже по неполной строке, напр.: 102563

[alibek]

Совпадающая часть - цифровая?

[VVitafresh]

Чаще всего -- да. Но код может в конце содержать буквы, напр.: AB 100-1102S-KM

[alibek]

Может сделать, как посоветовал Andrey Fedorov? Продублируй код товара в отдельном поле и ищи по нему.

[VVitafresh]

Что-то мне этот вариант не очень... Сильно разные коды встречаются с разным неведомым мне принципом построения, напр.:

Код: Выделить всё

AB 00-444-1121R-EDN
8HS 562 691-002
AKB1163 0.50MM
AS KN-122A
PO 50-324573-00
PR JM5019
TN MB04017BA


Как тут можно вычленить значимую часть, по которой создавать одельное поле