Страница 1 из 1
Cretae view
Добавлено: 07 июл 2011, 09:06
n0where
Решил разобраться с 2-мя вьюхами. Но так ничего путного и не придумал.
Можете помочь в решении.
Суть задачи:
Необходимо иметь 2 вьюхи, с 1 кидаем во временную таблицу, со второй через временную таблицу в tree выгружаем данные.
Альтернатива - добавлять в временную таблицу данные и потом их выводить не удобно ибо долго работает ))
Re: Cretae view
Добавлено: 07 июл 2011, 10:55
edward_K
а правил мало - теже что и в формах практически.
1. ко второй и последующей обращаетесь с указанием "имя_вью.", в том числе и к функциям навигации.
2. Дерево на второй и последующей не построить. Так что меняйте местами
3.не все функции пашут с указанием табл из разных вьюх. хотя мож и починили. Раньше был рантайм в "insert set;"
Re: Cretae view
Добавлено: 07 июл 2011, 11:19
n0where
Просто вьюха огромная и время занимает большое на чтение и отображение, хочется результаты запихнуть во временную таблицу дабы увеличить скорость работы.
Re: Cretae view
Добавлено: 07 июл 2011, 11:36
Den
А почему Вы решили что оптимальным решением тут будет 2 вью ?
n0where писал(а):
Просто вьюха огромная и время занимает большое на чтение и отображ
Что Вы понимаете под огромной вью ? кол-во таблиц в select или большой where ?
По поводу отображения тоже не очень понятно. Отображение идет через конкретный интерфейсный формат визуальный, в которой указывается таблица-корень этого формата. Размер вью тут не имеет решающего значения.
Re: Cretae view
Добавлено: 07 июл 2011, 11:47
edward_K
ну разбитием на вьюхи можно увеличить скорость на 30-50 процентов.
У меня в одном месте стояли sterr и синоним sterr.
Так вот убирание синонима повысило скорость раза в 3. Ну там миллион записей.
Re: Cretae view
Добавлено: 07 июл 2011, 12:29
Screw
Простой перенос узла из одной ЛТ в другую не даст прироста производительности. Дело не в наличии узла, а в его ограничениях и связях с другими.
До тех пор, пока Атлантису не требуется выборка данных (для отображения или расчётов), размер и структура ЛТ не имеет значения.
Re: Cretae view
Добавлено: 07 июл 2011, 12:45
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, т.е. если их сделать фиксированными, то и зависания не будет.
Re: Cretae view
Добавлено: 07 июл 2011, 13:25
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 ....
Re: Cretae view
Добавлено: 07 июл 2011, 15:38
n0where
Den
Ваши советы помогли, но остался один не решённый вопрос - нужно сделать такую весЧь.
Отфильтровать по значениям вычисляемых полей.
Если я делаю во where в виде фильтра ( условие ), то очень сильно тормозит вывод и отображение. в виде подцепки я сделать не могу ибо нет связи основной таблицы с вычисляемом поле.
Re: Cretae view
Добавлено: 07 июл 2011, 18:30
Den
Мдась..база то не на битриве ? Если нет, то сразу лучше сделать через прямой скуль. А так ,конечно, тяжко будет иннициализироваться фейс и навигация осуществляться (
Re: Cretae view
Добавлено: 07 июл 2011, 21:02
edward_K
вопрос с фильтрацией уже обсуждался
Только не condition!
Я так заполняю времянку и на нее накладываю bounds с жесткой подцепкой с основной - так навигация шустрее раз в 10.
Re: Cretae view
Добавлено: 08 июл 2011, 08:47
n0where
Так и сделал, может другие варианты будут
Re: Cretae view
Добавлено: 08 июл 2011, 10:04
oiko
Вьюха напоминает отчет по некоему сравнению данных.
А нужна ли такая вьюха? Интерактивно отслеживать изменения?
Может проще обойтись отчетом?
Re: Cretae view
Добавлено: 08 июл 2011, 11:37
n0where
oiko
Зависит от скорости работы. Если в скорости не прибавится (при фильтрах), то будет отчет, если да, то можно и актуальные данные смотреть
На данный момент реализовано через временные таблицы, аля отчет.