Roman V. Тривиальность задачи расчета остатков по ВСЕМ ТМЦ за КАЖДЫЙ рабочий день зависит от способа хранения и расчета остатков в БД.
Безусловно. Но, полагаю, Вы согласитесь с тем, что это стандартнейшая задача для любой складской системы, и она должна так или иначе решаться ядром системы, решаться во-первых удобно для "кастомизатора" (или кто там дописывает этот отчет), а во-вторых эффективно. То есть должна быть например заранее созданная вьюха, из которой автор отчета может эти остатки просто взять (и знать, что они придут достаточно быстро).
Roman V.И скорее всего, "тривиальный" SQL запрос не будет особенно отличаться от цикла по рабочим дням, используя встроеннный функционал.
С какой точки зрения? Если делать совсем с нуля, то примерно так:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
-- Формируем тестовые данные
SQL> create table movements ( item_id integer, value integer, movement_date date ) ;
Table created
SQL> insert into movements
2 select mod ( rownum, 3 ), round ( dbms_random.value ( - 10 , 10 )), trunc ( sysdate ) + rownum
3 from dual
4 connect by level <= 20 ;
20 rows inserted
SQL> select * from movements order by item_id, movement_date ;
ITEM_ID VALUE MOVEMENT_DATE
---------- ---------- -------------
0 - 4 10 . 04 . 2006
0 9 13 . 04 . 2006
0 8 16 . 04 . 2006
0 0 19 . 04 . 2006
0 - 8 22 . 04 . 2006
0 - 5 25 . 04 . 2006
1 7 08 . 04 . 2006
1 - 6 11 . 04 . 2006
1 - 4 14 . 04 . 2006
1 - 4 17 . 04 . 2006
1 4 20 . 04 . 2006
1 9 23 . 04 . 2006
1 0 26 . 04 . 2006
2 - 4 09 . 04 . 2006
2 1 12 . 04 . 2006
2 - 2 15 . 04 . 2006
2 9 18 . 04 . 2006
2 - 6 21 . 04 . 2006
2 - 9 24 . 04 . 2006
2 - 8 27 . 04 . 2006
20 rows selected
Теперь, если хочется посмотреть динамику остатков, простой запрос (надеюсь, простите отрицательные остатки - лень было вмешиваться в генерацию данных):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
SQL> select
2 item_id,
3 sum ( value ) over ( partition by item_id order by movement_date ) rest,
4 movement_date date_from,
5 lead ( movement_date ) over ( partition by item_id order by movement_date ) date_to
6 from
7 movements ;
ITEM_ID REST DATE_FROM DATE_TO
---------- ---------- ----------- -----------
0 - 4 10 . 04 . 2006 13 . 04 . 2006
0 5 13 . 04 . 2006 16 . 04 . 2006
0 13 16 . 04 . 2006 19 . 04 . 2006
0 13 19 . 04 . 2006 22 . 04 . 2006
0 5 22 . 04 . 2006 25 . 04 . 2006
0 0 25 . 04 . 2006
1 7 08 . 04 . 2006 11 . 04 . 2006
1 1 11 . 04 . 2006 14 . 04 . 2006
1 - 3 14 . 04 . 2006 17 . 04 . 2006
1 - 7 17 . 04 . 2006 20 . 04 . 2006
1 - 3 20 . 04 . 2006 23 . 04 . 2006
1 6 23 . 04 . 2006 26 . 04 . 2006
1 6 26 . 04 . 2006
2 - 4 09 . 04 . 2006 12 . 04 . 2006
2 - 3 12 . 04 . 2006 15 . 04 . 2006
2 - 5 15 . 04 . 2006 18 . 04 . 2006
2 4 18 . 04 . 2006 21 . 04 . 2006
2 - 2 21 . 04 . 2006 24 . 04 . 2006
2 - 11 24 . 04 . 2006 27 . 04 . 2006
2 - 19 27 . 04 . 2006
20 rows selected
Если хочется посмотреть, сколько дней в апреле присутствовал на складе тот или иной товар, легко используем предыдущий запрос:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
SQL> with
2 rests as ( select item_id,
3 sum ( value ) over
4 ( partition by item_id order by movement_date ) rest,
5 movement_date date_from,
6 lead ( movement_date ) over
7 ( partition by item_id order by movement_date ) date_to
8 from movements ),
9 days as ( select trunc ( sysdate ) + rownum day
10 from dual
11 connect by level <= 23 )
12 select
13 item_id,
14 count(*)
15 from
16 rests, days
17 where
18 days.day between rests.date_from and coalesce ( rests.date_to, days.day + 1 ) and
19 rests.rest > 0
20 group by
21 rests.item_id ;
ITEM_ID COUNT(*)
---------- ----------
0 16
1 17
2 4
Roman V.Это не недостаток КИС.
Недостаток КИС - гипотетическое отсутствие нормального механизма решения типичной задачи.
Roman V.Другое дело, если имеются не ОПЕРАТИВНЫЕ остатки, а уже выгруженные, расчитанные и неизменные данные за большой прошлый период
в какую-то базу, оптимизированную для таких статистических расчетов, например OLAP. Здесь конечно все может быть более оптимально.
Хм. Это напоминает стрельбу из пушки по воробьям. Остатки, безусловно, нужны в OLAP-е, но незачем перекладывать на него каждую встречную задачу.
