вадяmaytonПокеж.дай набор данных сделаю демку.

или могу выложть кусок кода который обрабатывает на сервере строку типа ыва ннн вааыв
преобразует её для динамического запроса в хранимке и по ответу строит таблицу для выподающего списка
Ну Окей.

Возьми базу данных NorthWind. Она часто публикуется в тексте. И найди в ней "123".

Но конечно хотелось-бы какое-то общее решение. Не для 1 таблички а для всех.

вадя,

Ты вообще не читаешь то что я пишу. Я решаю задачу в рамках 1 интерфейса который я предложил.

Ты решаешь другую задачу где есть 2 ключевых слова для поиска.

Это не моя постановка.

Лимит курсора есть почти во всех dbms. Но в данной задаче это ненужное 5 колесо.

Оставьте его в покое.

Подумайте почему в интерфейсе я заложил не List а Iterator в качестве типа возвращаемого значения.

И как это закодить в рамках множества таблиц.

вадяmaytonНо в данной задаче это ненужное 5 колесо.как раз в этой задаче и есть в этом ускорение, ограничение на вывод не нужной инфы
Если-б ты был DBA как я, то ты сразу-бы понял что задачи полного поиска по like не индексируются
никак и (почти!) никак не ускоряются. Можешь мне поверить я собаку скушал на этом. Мы на elastic
переходили чтобы поднять перформанс некоторых вещей.

Если текст курсора содержит выражение вида WHERE ... LIKE '%....%' и других предикатов нет - то
данный план всегда будет содержать FTS.

Исключение составляют
- специфичные LIKE выражения где нет метасимвола с фронта (например LIKE 'бла%'). В этом случае индекс на основе Б+Дерева может быть использован. Во всех остальных кейсах - нет.
- проприетарные технологии в Oracle (OracleText (CTX_CAT...)) при условии что в таблице 1 единственное поле и оно стоит под этим доменным индексом.
- проприетарные технологии PostgreSQL, MySQL, MS-SQL которые поддерживают индексы текстового поиска.

Беря во внимание мой Java-интерфейс и мою постановку вероятность этих специфичных кейсов практически равна нулю.
И затачивать под них генерализованный Jdbc поиск я не хочу.

Беря во внимание что никто не хочет искать выражение 'бла%' а все хотят искать выражение в любой части документа
данная LIKE оптимизация нам не поможет. Сюда-же до кучи функциональные индексы.

Ускорить FTS под Oracle можно для крупных partitioned таблиц при использовании hint +PARALLEL(n) в n процессов по аналогии
c фьючерсами в java. Для этого почти ничего не надо делать только детектировать тип DBMS (через DatabaseMetadata)
и активировать хинт.

Опять-же для данной задачи КМК важнее чтобы она работала концептуально правильно а уже всякие тюнинги можно
сделать потом как плагины изменяющие оригинальный текст запроса.

вадяmaytonПодумайте почему в интерфейсе я заложил не List а Iterator в качестве типа возвращаемого значения.лист или итератор - это будет не быстрее чем это сделать в субд.
если есть права - можно получить все данные о субд и по ним построить запрос по поиску нужных данных
записывать в лист или итератор скачанное из субд это не разумно, потому как память требуемую для лист/итератор лусше отдать субд она более правильно будет использовать.

Ну всё таки. Ты ПОНИМАЕШЬ зачем вообще в Java есть интерфейс Iterator? В чем его назначение? Зачем вообще
он выделен в отдельную сущность? Почему иерархия коллекций не завершилась на уровне List?

Почему я настаиваю именно на Iterator а не сделал просто List?

вадяmaytonЕсли-б ты был DBA как я, то ты сразу-бы понял что задачи полного поиска по like не индексируютсяя и не заявлял про индексы.
я знаю что like очень медленный поиск, но если сравнивать mysql 5.7 с версиями до 5.7 - можно увидеть десятикратную разницу . я не знаю чем они этого добились, но факт остаётся фактом.

и эта 1.6 сек для поиска в 3лямах я считаю вполне приемлемым . всё конечно зависит от задачи.

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

А важно то что текстовый поиск имеет другую (не-реляционную) природу. И в данном моём хакатоне я предложил
его реализовать если кто осилит. Впрочем я думаю что я перефразирую тему и форкну ее отдельным топиком.