Здравствуйте

Проблема такая:
Появилась задача реализации живого поиска: у Вас есть некий контрол на форме, пользователь что-то вводит в него и в выпадающем списке появляются элементы, начинающиеся с введенной последовательности символов.

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

Например, Вы ищете человека по фамилии. По первым 2 буквам нашлось 500 человек в базе, в кеш взято 300. Дальше при вводе 3 буквы надо принять решение:взять из кеша или обратиться к базе и обновить кеш.

Знаете ли Вы какие-нибудь паттерны решений такой задачи?

На форме находится 5 контролов с живым поиском. Каждый по 100 символов.
Примерное количество обращений к базе - 500 раз для заполнения данной формы.
Индекс есть и процесс выборки происходит быстро. Но 500 обращений хотелось бы сократить.

1. задание от пользователей - обновление выпадающего списка при вводе каждой буквы, начиная со 2-ой
2. 100 символов могут и не искать, но даже если и по 10 символам, то 5*10 = 50 обращений. Искать будут по всем 5 контролам, они никак не связаны.

По факту хватает 3-4 символов ввода, чтобы сократить в выпадающем списке количество вариантов до приемлемого количества - верно, и поэтому начиная с 5 символа можно обращаться только к кешу

petalvikмне_интересно,

нужна задержка по времени перед отправкой запроса в БД. То есть пока человек печатает быстро запроса нет. Как только закончил ввод - спустя долю секунды запрос уходит в БД.


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

получается так: напечатано 3 буквы, пауза, запрос пошел в бд. пока запрос идет, напечатано еще 2 буквы. результат надо снова быстро обновить, так как он не соответствует запросу. то есть в какой-то момент может наступить рассогласование. То есть, если основываться на времени, то надо как-то сериализовать последовательность <набор символов><обновление списка>, так?

hVosttмне_интересно По факту хватает 3-4 символов ввода, чтобы сократить в выпадающем списке количество вариантов до приемлемого количества - верно, и поэтому начиная с 5 символа можно обращаться только к кешу

А как ты себе представляешь такой кеш? Работает 1000 пользователей, каждый ввёл своих 3-4 символа, это что же на серваке надо «закешировать» для каждого «ключа» ввода в 3-4 символа свой набор данных с сотнями записей? Это не экономия получается, а глупое никчёмное расточительство оперативной памяти. Лучше уж сразу в память загрузить эти списки полностью и пусть они там лежат, если такой панический страх перед запросами к базе данных.

Не надо бороться с базой данных, она итак уже оптимизирована именно для работы с данными, отдавая их по запросу так быстро, как только это вообще возможно.

тут нужно сравнивать как расходуются ресурсы с использованием кеша и без использования кеша.

предположим кеш = 300 записей и 1000 пользователей.

с использованием кеша: в памяти висит 300.000 записей (каждая по 200 байт примерно)
без использования кеша: для каждого из 1000 пользователей идет обращение к базе несколько раз только для одного контрола, и каждое обращение тратит ресурсы как на стороне сервера, с которого идет обращение, так и со стороны сервера базы данных. То есть открывается сессия, идет авторизация, идет запрос и обновление таблицы DataTable.

что затратнее?