Фильтр DBGrid, Delphi.

Недавно я погрузился в мир Delphi, для своего текущего мини-проекта я получаю данные с помощью SQL-запроса, а затем использую свойство filter, чтобы отобразить именно то, что я хочу.

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

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

Я посмотрел онлайн, ресурсы заставляют меня верить, что это более эффективно, но я все еще не уверен. Спасибо за любую помощь.

Источник

2 ответа

Решение

Фильтр в наборе данных действительно работает (или, по крайней мере, ведет себя) как WHERE пункт, а в некоторых случаях может быть очень быстро.

Проблемы с зависимостью от фильтров:

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

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

  3. Увеличенное использование памяти и ЦП на клиенте для хранения данных, которые он не использует в памяти, и для обработки строк для фильтрации.

  4. Данные, обновленные другими пользователями или процессами, не видны клиентскому приложению, так как теперь вы работаете со всеми данными в локальной памяти и не обновляете данные с сервера.

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

Источник

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

Если ваше приложение и база данных работают на одной и той же машине, возможно, это ошибка.

Но если вы выполняете это в клиент-серверном, n-уровневом или многораздельном мобильном приложении, и это обычная операция, то я бы сказал, что вам, вероятно, лучше кэшировать больший набор результатов, полученных в одном запрос на стороне клиента и использование фильтров, чтобы позволить пользователям видеть различные представления результатов. Это уменьшает пропускную способность хоста, и пользователи получают более быстрое время отклика.

(Моя любимая мозоль - искать автомобили, квартиры или недвижимость, и я отмечаю или убираю флажок, чтобы изменить вид, и мне приходится ждать 5-10 секунд, чтобы приложение ответило.)

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

Часто фактические данные достаточно малы для каждой записи. Но когда вы добавляете медиа-материал, он взрывается. Люди часто не думают об этом, учитывая только совокупный размер каждой "записи", включая медиа-объекты. Если разработчик БД был умным, носитель информации даже не хранится в БД, а где-то еще, и доступен через URL-адреса.

Источник
Другие вопросы по тегам