Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
И снова про СКЛАДСКИЕ ОСТАТКИ...
|
|||
|---|---|---|---|
|
#18+
Проработав некоторое время с ОЛАП-ом могу предложить такой подход. Время представляем как иерархию год-месяц-день. (можно и по другому, тогда доп. таблицы будут другие) создаём 3 доп. таблицы: "движение по годам" - товар, год, "сумма приходов и расходов за год" "движение по месяцам" - товар, год, месяц, "сумма за месяц" "движение по дням" - товар, год, месяц, день, "сумма за день" Тогда при проведении документа надо будет тригером изменить всего лишь 3 числа - по одному в каждой из указанных выше таблиц Для получения остатка на любую дату надо будет сложить всего лишь несколько чисел: 1 - по предшествующим годам таблицы 1 (пусть в среднем 5 таких чисел) 2 - по предшествующим месяцам таблицы 2 (пусть в среднем 6 чисел) 3 - по предшествующим дням таблицы 3 (пусть в среднем 15 чисел) итого: редактирование - 3 операции подсчёт остатков - 26 операций Есть варианты быстрее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2004, 15:57 |
|
||
|
И снова про СКЛАДСКИЕ ОСТАТКИ...
|
|||
|---|---|---|---|
|
#18+
Дальше возможны вариации и различный баланс между временем пересчёта движений и временем получения остатков: Вариация с уменьшением времени расчёта остатков (увеличивается время проведения док-та) сделать таблицы "группа годов"-"год"-"полугодие"-"месяц"-"неделя"-"день" тогда при проведении документа 6 операций при расчёте остатков в среднем 1+2+1+3+2+3 = 12 операций (даже в сумме выйграли: было 29, стало 18. хотя может я не так усреднил) Вторая вариация в сторону уменьшения времени проведения документа (увеличивается время расчёта остатков) "кварталы всех годов"-"дни кварталов" проведение 2 операции расчёт в среднем 10+60 = 70 операций вырожденными(крайними) случаями применения этого подхода являются уже упомянутые участниками выше: 1. без доп. таблиц. При проведении ничего считать не надо, при расчёте остатка - несколько тысяч (сотен тысяч) 2. доп таблица с остатками на каждую дату. При проведении - очень длинный расчёт (по всем дням, которые позже даты документа). Расчёт остатков - мгновенно - одно число. Лучший выход, как известно, - золотая середина :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2004, 16:16 |
|
||
|
И снова про СКЛАДСКИЕ ОСТАТКИ...
|
|||
|---|---|---|---|
|
#18+
Расчёт остатков - сумма ближайшего промежуточного итога и сумма операций по журналу по (дата) between (ближ.промеж.дата+1) and (нужная дата) Использую union и агрегатную сумму по его результату :) Промежуточные остатки можно делать, например 1-2 раза в месяц. как вариант - вот такой запрос Код: plaintext 1. 2. 3. 4. Такой запрос - когда дата приходного расходного дока - в group by ItemID, Data_doc - на автомате сам считает остаток ....на любую дату "движения товара". Только вот даты здесь - как бы не все...а только, те что были реально... Такую фичу я бы сохранил в оракле в MV. и потот юзал ее - уже изучая остатки по артикулам и по датам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2004, 20:17 |
|
||
|
|

start [/forum/topic.php?fid=32&startmsg=32775816&tid=1546192]: |
0ms |
get settings: |
7ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
55ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 216ms |
| total: | 349ms |

| 0 / 0 |
