Галактика в вопросах и ответах

Имеем: Галактика 7.12 на MSSQL.
Хотим расчитать возвраты по с/ф.

.Create  view vMainRet
var cSchFact:comp;
as
select SpSopr.KolFact,SpSopr.doprttn,SpSchf.kolopl,SpSchf.Sum,SpSchf.Nds,SpSchf.PercNDS
from
  SpSchf,
  SpSopr SpSoprF,
  SpOrder,
  SpSopr
where
((
        cSchFact == SpSchf.cschfact
  and SpSchf.nrec == SpSoprF.cspschf
  and SpSoprF.nrec == SpOrder.cspsopr
  and SpOrder.nrec == SpSopr.csporder
));
...
vMainRet.cSchFact := nrec с/ф;

vMainRet._loop fullcache
{
         m_retkol := m_retkol + vMainRet.KolFact;
}
...

Проблема: очень низкая производительность работы.
С помощью SqlProfiler смотрим какие запросы отсылаются на MSSQL.
Алгоритм работы Галактики получается такой:
1) Получить одну запись из SpSchf;
2) Получить одну запись из SpSoprF;
3) Получить одну запись из SpOrder;
4) Получить одну запись из SpSopr;
5) Выполнить пункт 4 для всех записей, подпадающих под условие SpOrder.nrec == SpSopr.csporder
6) Выполнить пункты 3 и затем 4 для всех записей, подпадающих под условие SpSoprF.nrec == SpOrder.cspsopr
7) И т.д.
Смысл в том, что обработка всех таблиц идет циклически по очереди.
Естественно, что это чрезвычайно медленно.
На SQL данный запрос выполняется в один этап

Код: Выделить всё

select SpSopr.KolFact,SpSopr.doprttn,SpSchf.kolopl,SpSchf.Sum,SpSchf.Nds,SpSchf.PercNDS
from
  SpSchf
  inner join SpSopr SpSoprF on SpSoprF.cspschf = SpSchf.nrec 
  inner join SpOrder on SpOrder.cspsopr = SpSoprF.nrec 
  inner join SpSopr on SpSopr.csporder = SpOrder.nrec 
where
  SpSchf.cschfact = cSchFact

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

Забавно )
Может быть серьезные изменения в движке бы менять пришлось, вот и не стали с этми замарачиваться. А так на всех базах сама галактика через драйвер запросы выполняет собственным ущербным sql и все. Да и скока триггеров бы с SP пришлось писать им. Наверняка на стоимости бы сказалось.

А разработчики Атлантиса не удостаивают ,по всей видимости, сей форум вниманием.

По существу бы им пришлось еще раз весь прикладной код перелапатить (если бы путем писали серверную часть на TSQL...)

Den писал(а):По существу бы им пришлось еще раз весь прикладной код перелапатить (если бы путем писали серверную часть на TSQL...)

Да нет, этого никто не требует от разработчиков. Понятно, что Галактика многоплатформенная и использовать прикладную часть на T-SQL не может. Но, боже, что же так криво сделана работа с СУБД!!!
Галактика умеет делать JOIN таблицам, но только в том случае, если к таблице цепляются справочники. Я уверен на 99.99%, что реализовать нормальную работу с логическими таблицами не составит большого труда разработчикам. Неужели разработчики Галактики не понимают, что функционал это еще не все, нужно еще и быстродействие. Что толку от функционала, если программа тормозит на больших объемах данных.

А про join-ы узнал из Profiler-а ?

Den писал(а):А про join-ы узнал из Profiler-а ?

Естественно.

из vip программы при разборе логической таблицы join-ы делаются по уникальным ключам.
справа должно быть поле ,которое одно в уникальном индексе.
например rtable.cltable->ltable.nrec.
объединение нескольких таблиц на неуникальных индексах , более одного поля , в один запрос возможно через методы tDriver . доступно в потомках атлантиса на паскале. в протоколе при этом имеем сообщение "warning! filter non root table!".

san писал(а):из vip программы при разборе логической таблицы join-ы делаются по уникальным ключам.
справа должно быть поле ,которое одно в уникальном индексе.
например rtable.cltable->ltable.nrec.

В курсе, просто обычно это справочники поэтому так и написал.

san писал(а): объединение нескольких таблиц на неуникальных индексах , более одного поля , в один запрос возможно через методы tDriver . доступно в потомках атлантиса на паскале. в протоколе при этом имеем сообщение "warning! filter non root table!".

Из этого я понимаю, что обычным смертным так работать с лог.таблицей не удастся.
Разработчикам давно уже пора задуматься над переработкой движка по работе с СУБД.

[/quote]
Из этого я понимаю, что обычным смертным так работать с лог.таблицей не удастся.
Разработчикам давно уже пора задуматься над переработкой движка по работе с СУБД.[/quote]
Если бы в vip был реализован это несчастный filter non root table , подобные выборки получаются в среднем в 40 раз быстрее . Простой пример - три процедуры при работе с внешней классификацией.

Галактика в вопросах и ответах

Галактика, возвраты и MSSQL

Галактика, возвраты и MSSQL