Cretae view

[n0where]

Решил разобраться с 2-мя вьюхами. Но так ничего путного и не придумал.
Можете помочь в решении.

Суть задачи:
Необходимо иметь 2 вьюхи, с 1 кидаем во временную таблицу, со второй через временную таблицу в tree выгружаем данные.

Альтернатива - добавлять в временную таблицу данные и потом их выводить не удобно ибо долго работает ))

[edward_K]

а правил мало - теже что и в формах практически.
1. ко второй и последующей обращаетесь с указанием "имя_вью.", в том числе и к функциям навигации.
2. Дерево на второй и последующей не построить. Так что меняйте местами
3.не все функции пашут с указанием табл из разных вьюх. хотя мож и починили. Раньше был рантайм в "insert set;"

[n0where]

Просто вьюха огромная и время занимает большое на чтение и отображение, хочется результаты запихнуть во временную таблицу дабы увеличить скорость работы.

[Den]

А почему Вы решили что оптимальным решением тут будет 2 вью ?

Просто вьюха огромная и время занимает большое на чтение и отображ

Что Вы понимаете под огромной вью ? кол-во таблиц в select или большой where ?
По поводу отображения тоже не очень понятно. Отображение идет через конкретный интерфейсный формат визуальный, в которой указывается таблица-корень этого формата. Размер вью тут не имеет решающего значения.

[edward_K]

ну разбитием на вьюхи можно увеличить скорость на 30-50 процентов.
У меня в одном месте стояли sterr и синоним sterr.
Так вот убирание синонима повысило скорость раза в 3. Ну там миллион записей.

[Screw]

Простой перенос узла из одной ЛТ в другую не даст прироста производительности. Дело не в наличии узла, а в его ограничениях и связях с другими.
До тех пор, пока Атлантису не требуется выборка данных (для отображения или расчётов), размер и структура ЛТ не имеет значения.

[n0where]

Под огромной вьюхой я понимаю большое кол-во запросов к бд, вычислением поле и тп.

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

create view cvData
as select
  ( GetBuxSum1 ) ( FieldName = BuxSumOplPred ),
  ( GetBuxSum2 ) ( FieldName = BuxSumOplPost ),
  ( BuxSumOplPred+BuxSumOplPost ) ( FieldName = BuxSumOpl ),
  ( GetBuxSum3 ) ( FieldName = BuxSumOtgr ),
  ( BuxSumOpl-BuxSumOtgr ) ( FieldName = BuxSumSaldo ),
  ( GetOperSum2 ) ( FieldName = OperSumOpl ),
  ( GetOperSum1 ) ( FieldName = OperSumOtgr ),
  ( OperSumOpl-OperSumOtgr ) ( FieldName = OperSumSaldo ),
  ( BuxSumSaldo-OperSumSaldo ) ( FieldName = SumSaldo ),

  *
from
  OBOROT, KATSOPR, SPSOPR, KATORG, DOGOVOR, BASEDOC, BaseFin, StepDoc,
  synonym OBOROT OBOROT1,
  synonym OBOROT OBOROT2,
  synonym OBOROT OBOROT3
where ((
                 0 == BASEDOC.CVAL        (noIndex)
  and          201 == BASEDOC.VIDDOC      (noIndex)
  and     BASEDOC.CORG /== KATORG.NREC
  and BASEDOC.CDOGOVOR /== DOGOVOR.NREC
// БУХ АВАНС (Д62.01К62.02)
  and         '562'== OBOROT1.SCHETO      (noIndex)
  and         '01' == OBOROT1.SUBOSSCH    (noIndex)
  and         '562'== OBOROT1.SCHETK      (noIndex)
  and         '02' == OBOROT1.SUBSCHK     (noIndex)
  and BASEDOC.NREC == OBOROT1.KAUKS[4]    (noIndex)
// БУХ ПостОплата (К62.02)
  and         '562'== OBOROT2.SCHETK      (noIndex)
  and         '02' == OBOROT2.SUBSCHK     (noIndex)
  and BASEDOC.NREC == OBOROT2.KAUKS[4]    (noIndex)
  and  ( OBOROT2.SCHETO<>'562' )
// БУХ Отгрузка (Д62.02)
  and         '562'== OBOROT3.SCHETO      (noIndex)
  and         '02' == OBOROT3.SUBOSSCH    (noIndex)
  and BASEDOC.NREC == OBOROT3.KAUOS[4]    (noIndex)
  and  ( OBOROT3.SCHETK<>'562' )
// Опер Отгрузка
  and BASEDOC.NREC == STEPDOC.CBASEDOC
  and StepDoc.NREC == KATSOPR.CSTEPDOC
  and KATSOPR.NREC == SPSOPR.CSOPR
// Опер оплаты
  and BASEDOC.NREC == BASEFIN.CBASEDOC
));

function GetBuxSum1:double;
begin
  result := 0;
  cvData._loop OBOROT1 result := result + cvData.OBOROT1.SUMOB;
end;

function GetBuxSum2:double;
begin
  result := 0;
  cvData._loop OBOROT2 result := result + cvData.OBOROT2.SUMOB;
end;

function GetBuxSum3:double;
begin
  result := 0;
  cvData._loop OBOROT3 result := result + cvData.OBOROT3.SUMOB;
end;

function GetOperSum1:double;
begin
  result := 0;
  cvData._loop SPSOPR result := result + if(cvData.KATSOPR.VHODNAL=2,cvData.SPSOPR.KOLFACT*cvData.SPSOPR.PRICE+cvData.SPSOPR.SUMNDS,cvData.SPSOPR.KOLFACT*cvData.SPSOPR.PRICE);
end;

function GetOperSum2:double;
begin
  result := 0;
  cvData._loop BASEFIN result := result + if(cvData.BASEFIN.direct=1,cvData.BASEFIN.summa,-cvData.BASEFIN.summa);
end;

По поводу отображения тоже не очень понятно. Отображение идет через конкретный интерфейсный формат визуальный, в которой указывается таблица-корень этого формата. Размер вью тут не имеет решающего значения.

Что ж она тогда тормозит при переходе с одного поля на другое? Решил изза вычисляемых полей в select, т.е. если их сделать фиксированными, то и зависания не будет.

[Den]

1. Noindex стока это конечно не айс...
Попробуйте для начала переделать куски аля :

// БУХ АВАНС (Д62.01К62.02)
and '562'== OBOROT1.SCHETO (noIndex)
and '01' == OBOROT1.SUBOSSCH (noIndex)
and '562'== OBOROT1.SCHETK (noIndex)
and '02' == OBOROT1.SUBSCHK (noIndex)
and BASEDOC.NREC == OBOROT1.KAUKS[4] (noIndex)

на OBOROT51 индекс + узловой фильтр, т.е. :
...
and word(6) == OBOROT1.TBLKS[4]
and BASEDOC.NREC == OBOROT1.KAUKS[4]
and ( '562'= OBOROT1.SCHETO
'01' = OBOROT1.SUBOSSCH
'562'= OBOROT1.SCHETK
'02' = OBOROT1.SUBSCHK
)

2. Попробуйте уйти от функий аля вычисляемые поля у Вас , на вложенный подзапрос. Поиск по sum в доке и там вложенный подзапрос..

во вью будет что то вроде :
....
,(select sum(oborot.sumob) (fieldName=sumobor) from oborot where ((basedoc.nrec == oborot.cbasedoc)) )
не уверен правда что реально выигрыш будет, но попробовать можно.

3. Ну если уж не поможет все это существенно - то прямая дорога на предвыборку данных через dsql ....

[n0where]

Den
Ваши советы помогли, но остался один не решённый вопрос - нужно сделать такую весЧь.
Отфильтровать по значениям вычисляемых полей.

Если я делаю во where в виде фильтра ( условие ), то очень сильно тормозит вывод и отображение. в виде подцепки я сделать не могу ибо нет связи основной таблицы с вычисляемом поле.

[Den]

Мдась..база то не на битриве ? Если нет, то сразу лучше сделать через прямой скуль. А так ,конечно, тяжко будет иннициализироваться фейс и навигация осуществляться (

[edward_K]

вопрос с фильтрацией уже обсуждался
Только не condition!
Я так заполняю времянку и на нее накладываю bounds с жесткой подцепкой с основной - так навигация шустрее раз в 10.

[n0where]

Так и сделал, может другие варианты будут

[oiko]

Вьюха напоминает отчет по некоему сравнению данных.
А нужна ли такая вьюха? Интерактивно отслеживать изменения?
Может проще обойтись отчетом?

[n0where]

oiko
Зависит от скорости работы. Если в скорости не прибавится (при фильтрах), то будет отчет, если да, то можно и актуальные данные смотреть
На данный момент реализовано через временные таблицы, аля отчет.