Подскажите пожалуйста, как можно в запросе заставить драйвер FoxPro
использовать индексы?
В документации по Fox написано что он понимает индексные файлы CDX,
но в реальности запрос что с отбором по индексному полю, что нет - выполняется по времени практически
одинаково (отбор по одному элементу дает 10-20% выигрыша, по нескольким 10-20 проигрыша )
Проверял на нескольких совершенно разных запросах.

На форуме на эту тему ничего не нашел.
Используется доступ через oledb.

Например простой тестовый запрос  

    |SELECT  
    |	TablProdaz.Товар as [Товар $Справочник.Номенклатура]
    |	,SUM(TablProdaz.Количество) as Количество
    |	,SUM(TablProdaz.Себестоимость) as Себестоимость
    |	,SUM(TablProdaz.ПродСтоимость) as ПродСтоимость  
    |
    |FROM
    | (
    |    SELECT  
    |		$РегПродажи.Товар as Товар,
    |		$РегПродажи.Клиент as Клиент,
    |		$РегПродажи.Фирма as Фирма,
    |		$РегПродажи.Склад as Склад,
    |		$РегПродажи.Количество as Количество,
    |		$РегПродажи.Себестоимость as Себестоимость,
    |		$РегПродажи.ПродСтоимость as ПродСтоимость,
    |		РегПродажи.IDDoc as Док
    |	FROM
    |			$Регистр.Продажи as РегПродажи
    |	WHERE  (РегПродажи.Date BETWEEN :НачДата~~ AND :КонДата~~)
    |       AND($РегПродажи.Товар=:ВыбНоменкл)  // этого условия нет, когда по всем товарам
    |) as TablProdaz  
    |GROUP BY   Товар
 

На измерение Товар регистра Продажи повесим "отбор движений"
Результаты замеров :
_________________________________

С индексом

По выб товару   : 0.115с
По всем товарам : 0.426с
_________________________________

Без индекса

По выб   товару : 0.125с
По всем товарам : 0.435с
_________________________________

Описание поля таблицы движений при установке индекса


#-----Fields-------
F=SP5227    |(P)Товар
#----Indexes------
I=VIA5227  |VIA5227       |0     |SP5227,DATE,TIME,IDDOC,LINENO,ACTNO    

________________________________  

Как видно от установки индекса время выполнения практически не влияет.
Это тестовый пример. В реальной базе также никаких отличий не нашел.
Особенно это плохо из за с таблицы Констант
(Индекс : ID,OBJID...   )  и 1SJOURN.

В Fox е можно в процедурах указывать индекс. Может и здесь как то можно?

В качестве up.
Чтобы драйвер лучше понимал запрос условие  изменено на

|WHERE        ($РегПродажи.Товар=:ВыбНоменкл)  
|          AND  (РегПродажи.Date BETWEEN :НачДата~~ AND :КонДата~~)
 

Т.е. в ряде условий поле с индексом вынесено на первое место.
Наблюдается ускорение. Опять никак не связанное с наличием или отсутствием индекса.

Также испытание проведено по ряду запросов в живой базе, 30 человек.
Отмечена закономерность - чем селективнее запрос - тем быстрее работает 1С запрос,
запрос 1С++ убыстряется крайне незначительно.
На одном товаре уже наблюдается проигрыш прямого запроса.

Вообщем если не решить проблему с индексами, получается что прямые запросы на ДБФ базах
представляют интерес только для выборок без отборов, а это менее 10% всех запросов к базе.

Может все таки есть какое нибудь решение?

Возможно проблема связана с режимом сортирировки
"каждый индекс в отдельности запоминает тот режим сортировки при котором он был создан "
http://www.foxclub.ru/articles/index.php?id=35
Изменение в строке подключения

|Collating Sequence=RUSSIAN; 

на

|Collating Sequence=MACHINE;  

дало по предыдущему запросу

прямой запрос (Collating Sequence=MACHINE)

все товары---------------- 1.15
группа товаров---------- 1.00
два товара---------------- 0.77
один товар---------------- 0.75

Если кто использует ДБФ - проверьте пожалуйста (чтобы база не лежала только локально и было подключено несколько человек)

Выкладываю тест.
Подходит для любых конфигураций на торговле, где есть регистр
с измерением типа Документ и измерением "Номенклатура","Количество".
Запрос динамический, т.е. создание таблиц не используется.
По умолчанию данные под типовую торговлю

В запросе используется соединение регистра с журналом по IDDOC - как с наиболее тяжелой таблицей,
и у которой есть индекс по IDDOC.

На маленьких базах(демо) использовать не очень корректно , так как затраты на компиляцию занимают
основное время.

Так, срочно переходим на такой вариант
Ужас, а ты проверял этот вариант на выборке с top 1 ?
будет ли ускорение по сравнению с прошлым разом?

varelchik писал(а) 25. Апреля 2007 :: 06:12:


В этом нет ничего удивительного. Судя по запросу сначала драйверу надо соединить
таблицы по iddoc (возможно используя индекс) и лишь потом убрать лишнее.

Если селективность по дате выше чем по iddoc можно использовать

        |Select $Рег.Товар ,
	|sum($Рег.Количество) as Кол
	|from 1sjourn as Журнал  
	|left join   $Регистр.Продажи as Рег
	|         on Журнал.iddoc=right(Рег.iddoc,9)  
	|where  Журнал.date between :НачДата~~ and :КонДата~~
	|       AND (Журнал.$ФлагРегистра.Продажи = 1)
	|Group by $Рег.Товар  

Как видно одновременно и то и другое сделать не получается без установки флага быстрой обработки движений.
Что сам делаю и советую. Тем более оборотный регистр.
........
Uzhast писал(а) 24. Апреля 2007 :: 20:06:

Да, большое спасибо , учту при написаниии запросов

.....
Кстати, в описании индексов 1SJOURN в файле 1Cv7.DD встречается DOCNO(UPPER)
Между тем для Fox в режиме национальной сортировки регистр букв игнорируется.

artbear писал(а) 25. Апреля 2007 :: 04:57:

А смысл? И так ведь понятно, что драйвер такие запросы обрабатывает неоптимально. Или ты про сервис-пак? Надо будет еще сервис-пак погонять...

Вообще, ИМХО, в исходном запросе проявляется недостаточность мозгов у драйвера. Он вообще умный, но не всегда В запросе делается сначала выборка по 1sjourn, а потом она джойнится с резервами. Вероятно, драйвер делает полную выборку по 1sjourn, а потом отсеивает ненужное при помощи джойна. 1sjourn содержит заголовки всех документов за все время жизни базы. В результате, выборка по этой таблице занимает бОльшую часть времени выполнения запроса. Поэтому фильтры по товару почти не оказывают влияния на время запроса.

Как говорится, "на оптимизатор надейся, но и сам не плошай" Лучше запрос начинать с таблицы, которая даст наименьшее количество записей, а потом к ней уже джойниться. В данном случае это резервы.