Хранение еженедельных и ежемесячных агрегатов в Oracle

Question

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

Какова наилучшая структура таблицы для удержания продаж за период?

• Сохранить тип периода (M, W) с датами начала и окончания или только тип и дату начала?
• Используйте поля даты и символ или закодируйте его в строку ('M201201' / 'W201248')
• Нормализовать продажи и периоды в две таблицы или сохранить продажи и период в одной таблице?

Я буду выполнять два вида запросов - выбрать продажи текущего еженедельного (или ежемесячного) периода / клиента / статьи, но не обновлять их, и выбрать для обновления еженедельных и ежемесячных периодов для клиента / статьи.

Answer 1

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

Очень прямо и просто сказать where @date_of_interest >= start_date and @date_of_interest <= end_date. Любая другая комбинация требует от вас арифметики дат либо в коде, прежде чем перейти к вашему запросу, либо в самом запросе.

Сохранение кода типа (M, W), а также даты начала и окончания влечет за собой некоторую избыточность. Однако вы можете ввести эту избыточность для упрощения поиска данных. Это: where @date_of_interest >= start_date and @date_of_interest <= end_date and range_type='M' также очень прямолинейно и просто.

Как и при любой денормализации, вам необходимо убедиться, что у вас есть средства управления, которые будут управлять этой избыточностью.

Answer 2

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

Возможно, что-то вроде этого образца

product_prices (
    prod_code,
    price,
    date_price_begin
);

sales (
    prod_code,
    customer_code,
    sale_date
);


<aggregate-week>
select trunc(sale_date,'w') as week,
    prod_code,
    customer_code,
    sum(price) keep (dense_rank first order by date_price_start) as price
from sales 
    natural join product_prices
where sale_date > date_from
group by trunc(sale_date,'iw'),
    prod_code,
    customer_code
/

<aggregate-month>
select trunc(sale_date,'m') as month,
    prod_code,
    customer_code,
    sum(price) keep (dense_rank first order by date_price_start) as price
from sales 
    natural join product_prices
where sale_date > date_from
group by trunc(sale_date,'m'),
    prod_code,
    customer_code
/