aZmмда. еще раз. нафига козе баян? каким образом вы собираетесь решать проблему оптимизации запросов на клиенте? если вы вытащили некую выборку на клиента, а потом делаете еще 1 селект? уже на клиенте?

сервер, знаете ли, в случае подзапроса\вьюхи - просто раскроет скобки и подхватит наиболее подходящий индекс, выбрав наиболее оптимальный механизм джойна. а на клиенте что делать? у вас есть просто набор неких данных. все. ни про индексы, ни про расположение этих данных ничего не известно. КАК оптимизировать? без оптимизации? нюню :) тут уже нет разницы принципиальной - тупо прогонять циклами, используя свои механизмы сортировки, или использывать некий кастрированный диалект sql

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

Пример (несколько надуманный, но ведь мы договорились использовать только SQL-команды, никаких циклов ;-)).
Во время редактирования заказа с множеством строк в форме требуется пересчитывать сумму (итого) заказа и отображать в поле формы.
Если расчет суммы выполняется в ХП на сервере (select sum(...)...), то мы должны будем сначала, как минимум, сохранить измененные данные в БД, и только после этого выполнить ХП (запрос) и вернуть на клиента сумму заказа. Затем продолжим редактирование, опять сохраним, опять выполним ХП. А в таблице строк заказов миллионы записей. Ну да, оптимизация есть, но мы выбираем сумму по нескольким строкам из миллионов. Плюс к тому, выполняем много транзакций записи в таблицу, что вызывает перестроение индексов. Плюс к тому, выполняем запрос в условиях конкуренции. Если же среда, в которой реализована клиентская часть, позволяет работу с помощью SQL-команд с оторванными рекордсетами, которые уже на клиенте, то мы можем не дернуть сервер ни разу с момента начала работы над корректировкой заказа, сохранив все изменения потом скопом, а сумму пересчитывая, делая запрос к рекордсету строк заказа. Здесь у нас фулл-скан, а такие вещи без индексов быстрее, чем при их наличии работают, даже не беря в расчет отсутствие конкуренции и ускорение за счет исключения медленного канала связи (даже если сеть гигабитная, это медленный канал, по сравнению с обращением к ОЗУ или локальному жесткому диску).

Кстати, оптимизатор FoxPro хорош, он правильные индексы сам выбирает. Ну да, при желании добиться максимального быстродействия приходится несколько вариаций одного и того же запроса писать и тестировать скорость их выполнения на данных, близких к реальным, чтобы выбрать лучшую. Оптимизатор стал в 9-ке умнее. Раньше конструкции типа select a from ta where b not in (select b from tb) плохо оптимизировал, а варианты с exists - лучше, в последней версии же тесты показывают, что not in стал быстрее.
(Кстати, назовите хоть один оптимизатор запросов серверной БД, который, если использовать его в режиме полного автомата, всегда будет разбирать запрос именно так, чтобы в итоге данные были получены наискорейшим из возможных способом. Ну да, в Oracle можно подсказать, какой план выбрать, ткнуть в нужный индекс и т.д. В FoxPro это нельзя сделать, зато оптимизатор и на автомате прекрасно работает.)

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

Да, конечно. Лучше всего иметь возможность включить в единый запрос и локальные рекордсеты, и таблицы на сервере. Ну и что мы имеем: FoxPro (правда, только при том варианте, что мы будем работать с БД на основе его родных DBF, т.е. по ФС-варианту) это позволяет! Во как! ;-)))

Да, добавлю для полного счастья, что по локальным рекордсетам (ну, т.е., курсорам) в FoxPro можно построить индексы, как и по таблицам БД. Ну и что, что строится долго, зато потом оптимизация при последующем join-е полная ;-)

PPS: "Долго" - это не подходящий термин. Я имел в виду, что на построение индекса затрачивается определенное время. Которое зависит от объема выборки, количества индексов и сложности выражений, на основе которых они построены. При разумном объеме выборки временные затраты на создание индекса редко превышают десяток-другой миллисекунд.