Почитал вот это http://forum.sources.ru/index.php?showtopic=75714 (Переходим на клиент-сервер (советы))
Но осталось много вопросов.

Сразу скажу, что это применительно к связке MS SQL Server + C++Builder + ADO.
Плюс это применительно для работы через Интернет. В локали все работает нормально и так.

1) Допустим есть таблица с заказами.
Пользователь может осуществлять поиск, фильтрацию или просматривать в табличном виде записи, которые могут в зависимости от состояния заказа быть помечены другим цветом и т.п.
Т.е. работа с таблицей посредством лишь запроса к конкретной записи невозможна.
Как все же оптимизировать и ускорить работу?

У меня Grid и пользователь по нему "гуляет". Как оптимизировать так, чтобы подгружались только выводимые на экран записи? Или раз выполнился запрос - будьте любезны подкачать X байт данных со всеми результатами? Т.е. для оптимизации потребуется писать свой грид на основе TListView допустим. Т.е. делать сначала запрос с SELECT ID... а потом при отображении грида будем уже для ID видных на экране подгружать запись целиком. Т.е. перемещаясь у нас одна за одной записи будут подгружаться. Обратно вверх идем - все уже загружено и ничего грузиться не будет. Или может другие способы есть?

Пример второй - есть таблица запчастей. Скажем 10000 записей. Инвентаризационный запрос с группировкой вернет нам, скажем, 1500 наименований. Это занимает приличный объем и никакие средства и архитектуры не помогут сократить траффик и скорость генерации отчета. Я правильно понимаю?

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

Как тогда быть? Ограничить при работе через Интернет работу с заказами только через поиск?
Ну а если у нас идет ремонт заказа и надо на складе найти нужную запчасть, а их у нас 1000 наименований. И пользователь не всегда сможет составить грамотный запрос, чтобы у него было мало записей. Он введет "Samsung" и все запчасти этой марки попадут в список.

Или допустим хозяин мастерской хочет посмотреть "зависшие заказы" на удаленной точке.
Их может быть и много. Он выбрал фильтрацию по таким заказам и получил табличку в 100 записей (из 10000). Там приличный траффик будет.

Как быть?

2) Есть таблица-справочник.
Она пополняемая. Т.е. если после какой-то операции видно, что пользователь указал новые данные, то таблица пополняется.

Как рациональней - грузить изначально всю таблицу все-таки в TADOTable, который потом после Insert'а на сервер новую запись скинет, или же постоянно пользоваться для организации выбора из справочника запросами?

Тут поясню - помимо основного приложения, есть дополнительная программка, которая обменивается командами между сервером и клиентами. Т.е. я подумал - для чего мне при организации меню пользователя каждый раз делать Query, я лучше подгружу Table, а если добавлю записи, то пошлю серверку команду, а тот уже объявит клиентам другим, что таблича со справочником пополнилась и они ее обновят. Мне кажется запросов при такой организации куда меньше (т.е. если данные не добавлялись, то при организации меню будет всего один запрос - при старте программы).

Или может посоветуете что-то оптимальней со справочником?

3) Есть таблица. Часть данных видны пользователю, часть служебная информация.
При работе с записью нужны все поля (много).
Для отображения в гриде - только часть (десяток).
Что выгоднее - использовать один QUERY * и использовать его и для отображения таблицы и для работы с записью, или же для отображения таблицы использовать один запрос (только с нужными данными в SELECT'е), а потом после того, как пользователь выбрал какую-то запись, то делать еще один запрос "SELECT * WHERE ID=..."? Понятно, что во втором случае траффик снизится, но что будет с производительностью? Каждый раз перемещаясь по записи будет новый запрос на выборку всех оставшихся данных...

4) Я правильно понял, что TADOTable равносилен запросу SELECT *?

5) Есть ли какие-нибудь ключи ConnectionString или особенности использования TADOTable, TADOQuery, TDataSource и TBDGrid, которые бы помогли хоть немного снизить нагрузку на Интернет-канал? Или все в руках того, кто выстраивает систему запросов?

1) Вот насчет траффика.
>> Есть грид. Загружаю данные (первый запрос).
Вот какой объем таблицы получается? Сколько записей и полей?

Чем ADODataSet и ADOCommand предпочтительнее?

>> пользователь ввел какие-то данные в поля поиска формы
У вас поиск после нажатия кнопки или динамический в процессе ввода?

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

3) Ну так вот и планирую переделать.

2 Goffman
Ты делай как Яндекс, он же не загружает на одну страницу все результаты поиска.
Показал первые 20 записей, если юзер тыктнул кнопку "2" - загрузил из БД следующие 20 записей и т.д.
Тоже верно.
Т.е. ввести страницы по X записей и дергать потом в запросе записи в зависимости от номера страницы.

2 edges7
А вы их попробуйте. :)
Можно и позаменять, конечно, но вы расскажите в чем же преимущество?

Как-то заюзал SugarCRM (Web-интерфейс, Web-сервер Apache, PHP, СУБД MS SQL Server 2005). Запустил приложение, запустил профайлер. Знаете сколько запросов выполняется на каждый "чих"? :)
Количество не важно - сервер переварит. Важен объем данных. Чтобы траффика не очень много кушалось.