У меня есть код поиска
Дата может быть введена не полной, например 12 день либо 12:00. И имя с фамилией вводятся в одной ячейке и "могут вводится абы как" (для удобства пользователя всё)


он рабочий, всё хорошо показывает, только боюсь что при большой базе дынных будет тормозить.
Думаю что это можно улучшить при помощи индексации, только не знаю как точно
Можете ктонибудь объяснить как это дело делается

Если у Вас значение для LIKE начинается с %, то никакой индекс не поможет.

Это сообщение отредактировал(а) lazycat - 19.4.2012, 13:54

А реально-ли сделать индекс на TO_CHAR(a.timestamp)
чтобы при запросе брались заранее подсчитанные значения TO_CHAR(a.timestamp).
Другими словами не вводить столбец TO_CHAR(a.timestamp) в таблицу где будет хранится заранее подсчитанные значения TO_CHAR(a.timestamp)?

для начала на больших объемах данных будет тормозить в первую очередь Lower/Upper, построй индекс lower(<поле>)
сталкивался с подобной проблемой на ~70 млн. записей (порядка 5 столбцов для поиска) СУБД - ORACLE



также можеш подготовить мат. представления для набора данных, в котором ищеш, и периодически эти представления обновлять

Это сообщение отредактировал(а) 0x00 - 2.5.2012, 15:37

Насколько я вчитался, могу предложить сделать так:

Если фамилия и имя для поиска вбиваются четко, просто в разном порядке(но мы умеем их переставить в нужный) и с неопределенным регистром, то можно попробовать хэш.
То есть брать lastname и firstname, ставить в нужном порядке, оба загонять в lovercase(), по каждому из них брать String.hashcode(), потом делать общий хэшкод(в идее сгенерить, например по двум этим стринг полям). Полученный числовой хэш хранить в отдельном инт поле, которое проиндексировать.
Эту функцию хешкода можно повесить на саму энтити, но обзывать не hashcode(), так как оно выполняет частную функцию.

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

ЗЫ: оракл ничего знать не должен, все хеширование должно проводиться одним и тем же методом наверху, иначе хэшфункции оракла и джава кода могут в любой момент разъехаться и будет гемор.

Или реализовать это все с помощью function-based индекса где сделать то же самое (lovercase, concat, hash) и на поиск отдавать тоже через эти функции.


ЗЗЫ: Если в фамилиях допскаются опечатки (Сафронов-Софронов) - сделать или поискать словарик буквозамен. А-О, Ы-И. Все буквы заменяются через словарик, из Сафронова, Софронова и Сафранова получается Софронов и его-то мы хешируем.
То есть с т.з. хэша в БД у нас лежат только Софроновы мы их всех находим и потом уже наверху разбираемся кто Сафронов, а кто Софронов.
Если словарик будет реализован коряво - будут нюансы. Если не учитывает всех вариантов - может пропускать записи. Для поисковиков канает, для бухгалтерии - нихт :(


ЗЗЗЫ: Если могут вбивать "софр", "офро", "онов" - тогда ничего не попишешь :(
Хотя, посмотри на полнотекстовые индексы, я их в продакшне не пользовал, но подозреваю ;)