Фильтрация в компонентах доступа к данным (Delphi)
В Delphi для доступа к данным БД используется, в основном, компонент TTable (или его аналоги TADOTable, TSQLTable и пр.). У этих компонентов есть свойства Filter и Filtered, отвечаючие за фильтрацию выборки по строкам. Итак,
1) Я создаю пустое приложение, ложу туда, например TADOTable
2) Настраиваю подключение к серверу БД (у меня - SQL Server)
3) Выбираю имя таблицы в свойстве TableName, напр., MyTable
4) Задаю фильтр, например, "DocCode>='25.12.2003'" и устанавливаю свойство Filtered в True
5) Открываю таблицу
6) Если на шаге 5 посмотреть Trace-лог SQL-Server'а (я для этого пользуюсь утилитой MS SQL Profiler), то в нем будет не строка вида "SELECT * FROM MyTable WHERE DocCode>='25.12.2003'", а "SELECT * FROM MyTable", т.е. с сервера производится выборка не отфильтрованного набора данных, а полного.
7) Эксперименты с CursorType, LockType, другими библиотеками компонентов (TTable, TSQLSimpleTable) ничего не дали.
ИТОГ: Если у меня есть таблица с огромным числом записей, а я хочу открыть только небольшое их количество с исп. фильтра, то компонент доступа к данным все равно вытянет с сервера полный (неотфильтрованный) набор данных, а потом отфильтрует его локально. Тормоза при этом такие же, как если бы фильтра не было вообще. Побороть это невозможно, разве что пользоваться TQuery. Но это не подходит, т.к. там не свойств Filtered, Sort, MasterSource, которые так нужны! А писать своего наследника от TQuery некогда. :-( ...
Кто может хоть что-нибудь подсказать по этому поводу?
Компоненты типа Table используются в основном для локальных БД, типа убогого Paradox или Access. А всё скачивают они потому что у них такой алгоритм работы, который даёт лучшую производительность на локальных БД. Для распределённых БД лучше использовать AdoQuery. Св-во Filtered в AdoQuery есть, но не нужно, также вобщем как и Sort, потому что там всё решается с помощью SQL запросов вводимых через одноимённое св-во. Строишь запрос типа: Select * from zzz where IdNum>5 order by name. И радуешься жизни. Что касается MasterSource, то он на сколько я помню нужен для связи таблиц. Если очень хочешь вязать их на клиенте и не заморачиваться нормальной организацией БД, то вяжи их руками на событиях типа AfterPost. Но лучше вязать их на сервере.
Все это мне, в общем-то, и так понятно. Просто я думал, что я как-то не так использую TTable. Видать, придется-таки писать свой аналог TTable, унаследованный от TQuery. :(
Немного не понял, что ты имеешь в виду "вязать на клиенте" и "вязать на сервере". Если ты имеешь в виду ссылочную целостность (Referential Integrity), первичные и внешние ключи - так это само собой. А те связи, что есть на клиенте - так это исключительно для более удобного представления данных пользователю, не более того.
Кстати, я вспомнил, что замена MasterSource у TQuery все же есть - это свойство DataSource. Если запрос параметризованный и назначено свойство DataSource, то компонент автоматически подставляет в параметры значения тех полей из MasterSource.DataSet, имена которых совпадают с именами параметров. Это гораздо лучше, чем изголяться с событиями. ;)
Если чесно, хоть убей не могу понять, нафига использовать фильтрацию, вместо запросов.
Я под этим понимал, что например при занесении в таблицу каких-то данных, нужно занести ещё какие-нибудь данные в другую таблицу, то такие вещи некоторые люди делают на стороне клиента, на delphi. Когда можно просто написать маленький триггер и повесить его на сервер. Это сльно облегчает жизнь и уменьшает код.
Если чесно, хоть убей не могу понять, нафига использовать фильтрацию, вместо запросов.
Запросы идеальны для тех случаев, когда требуется только ВЫБОРКА данных. А когда нужно из изменение - тут, батенька, не все так просто. Далеко не каждый Query возвращает Live-набор данных (т.е., позволяющий себя изменять).
Фильтрация нужна, так как в нашем приложении фильтр может меняться динамически в процессе работы приложения (самим пользователем, с помощью специального конструктора). Я понимаю, что можно просто менять WHERE - фразу в запросе для смены фильтра. Да только это должно быть автоматизировано, потому как таких форм с user-фильтром у меня не меньше сотни и на каждой писать код перестройки текста запроса было бы глупо. Понятно, что здесь нужен свой компонент. Я-то его сделаю, и свойство "фильтр" туда добавлю, да только основной секс там будет именно с поддержкой обновления / добавления / удаления данных. :(
Все равно, спасибо за ответ.
Запросы идеальны для тех случаев, когда требуется только ВЫБОРКА данных. А когда нужно из изменение - тут, батенька, не все так просто. Далеко не каждый Query возвращает Live-набор данных (т.е., позволяющий себя изменять).
Фильтрация нужна, так как в нашем приложении фильтр может меняться динамически в процессе работы приложения (самим пользователем, с помощью специального конструктора). Я понимаю, что можно просто менять WHERE - фразу в запросе для смены фильтра. Да только это должно быть автоматизировано, потому как таких форм с user-фильтром у меня не меньше сотни и на каждой писать код перестройки текста запроса было бы глупо. Понятно, что здесь нужен свой компонент. Я-то его сделаю, и свойство "фильтр" туда добавлю, да только основной секс там будет именно с поддержкой обновления / добавления / удаления данных. :(
Все равно, спасибо за ответ.
Пожалуйста, кстати если не очень охото напрягаться со всей этой байдой и есть свободное время. Можешь посмотреть компоненты SDAC.
http://crlab.com/sdac/
Правда они не халявные, а на кряки для триала я не натыкался. Я сейчас использую ODAC их аналог, но только для Oracle. Вещь очень хорошая и работать удобней чем с ADO. Там есть и грид который сортирует данные по щелчку на title и поля в Query есть поле для раздела WHERE, вобщем если есть время можешь скачать триал и поиграться.