AviDen
Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
DmitryKz, если б это был не firebird, а ms sql server, я бы объяснил причину быстрой работы повторной фильтрации с тем же выражением фильтра наличием требуемых данных в кеше. Но иногда они вытесняются другими (с базой-то и другие юзеры работают!) и тогда серваку приходится запрашивать данные для фильтрации не их оперативы, а с диска. Частично решается 1) увеличением отводимой процессу сервера памяти 2) оптимизацией структуры таблицы, по которой делается поиск (кстати, я ж думаю, индекс по искомому полю-то у вас есть?)
А вообще, я бы всё делал в точности, как написал VadimLou - фильтровал хотябы от 2 (лучше 3) букв и подтягивал не более N записей, остальные - либо с задеркой, либо при попытке пользователя погулять по гриду.
Добавлено:
Cryogen2003, стандартный TDataSet НИКАК не определяет форматы хранения выбранных с сервера данных и практически не предъявляет никаких требований к их кешированию. Он вообще жестко не задаёт никаких рамок ни для каких аспектов манипулирования данными (выборка, кеширование, хранение, модификация, навигация и пр.). Всё это - прерогатива конкретного наследника.
С оракловскими БД я, к сожалению, не работал, поэтому сказать ничего определённого не могу. Но как-то я сильно сомневаюсь, чтобы там захаркодено было на каждое поле (любого типа) каждой записи выделять over 6КБ данных, ибо это попахивает маразмом. Может, имелся в виду какой-то конкретный пример? |
