Господа, ситуация следующая:

есть таблица фактов, содержащая данные по продажам (дата, ID номенклатуры, .....и.т.д.)

есть таблица цен, со следующими полями:

Дата начала периода действия
Дата конца периода действия
Тариф (тип цены)
ID номенклатуры
Цена

в конечной "витрине"(view) необходимо вытянуть порядка 7 цен по различным прайс-листам (в т.ч. себестоимость и др...)

время выполнения запроса с учетом цен увеличивается более чем в 2 раза по сравнению с view без цен..

кто-нибудь сталкивался с подобной задачей? подскажите плз, как можно более оптимально сделать схему хранения и выполнения запросов к такой информации??

прошу прощения за безграмотность но с термином PivotTable не знаком - видимо это из MS....
у нас БД Oracle 10g

абсолютные цифры: 240 секунд и 560 секунд - полностью выполнение запроса за один месяц.

текст исполняемого запроса прибл-но следующий:

select df.doc_date,
df.doc_type,
df.agn_id,
df.nomen_id,
f_get_price(df.doc_date,df.nomen_id,'SRT') nprice_srt,
..............................
from t_doc_facts df


f_get_price содержит в себе следующий запрос:

select t.price
into Result
from at_wh_prices t
where t.nomen_rn = nNOMEN_ID
and t.tariff = STARIFF
and t.price_date <= DDATE and (t.end_date >=DDATE or t.end_date is null)

где nNOMEN_ID, STARIFF, DDATE - параметры передаваемые предыдущим селектом

индексы стоят на всех полях таблицы at_wh_prices по которым идет выборка...

Ок, насчет pivot я кажется понял - в принципе наверное это как раз оно, либо похоже:
т.е. цены хранящиеся в строках (правда все типы цен(тарифы) хранятся в 1 таблице), преобразуются в 1 строку

от ф-ции попробую избавиться-просто изначально так было проще :)

Goster а можно поподробнее о
GosterВо-вторых - рассмотрите вариант хранения цен в таблице фактов.
плз???

Goster
Ну, храните значение f_get_price(df.doc_date,df.nomen_id,'SRT') в таблице t_doc_facts. :)

Таблица фактов - это по сути - показатели + ссылки на значения таблиц, содержащих члемы измерений. А у вас показатель также является ссылкой. Что, возможно, не совсем правильно. Хотя, на самом деле, все зависит от вариантов использования. Опять же - не понятно, является ли цена в данном случае показателем.
Как вариант - храните там rowid'ы таблицы с ценами.

да, цены у нас в таблице фактов - это показатели,
я вас понял, но тогда получается увеличится время ETL, за счет увеличения времени формирования таблицы фактов?? :)

про rowid'ы что-то я опять не совсем понял :) что это даст? хранить в таблице фактов, как ссылки на цены??

Goster
Ну, как обычно - или уменьшаем время загрузки и объем, или уменьшаем время запроса. А вы как хотели? И на елку влезть и зад не ободрать? :)) Может вам здесь кто-нибудь что-то еще подскажет, но я бы на вашем месте обратился с вопросом по производительности запроса в форум по Oracle. Там быстрее помогут.


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

Спасибо !!!