ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / И снова про СКЛАДСКИЕ ОСТАТКИ...
53 сообщений из 53, показаны все 3 страниц
  все  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32668771
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Понимаю, что на тему остатков уже писано-переписано, но тем не менее это вечно живая тема... :)
У кого какой опыт по проектированию/получению Sabj ?
Обязательные условия:
- огромный товарооборот и удовлетворительная производительность;
- хранение всех операций не менее, чем за год;
- партионный мультискладовый учёт;
- возможность получения остатков на любую дату и по любой комбинации складов;
- возможность урезки базы без потери правильности данных за открытый период;
- возможность прихода/продажи задним числом.

Мой опыт:

В основе две таблицы:
Товарный журнал со всеми операциями (упрощенно) : Operation_ID, Document_ID, OperationTypeID, OperationDate, ItemID, AdrFromID, AdrToID, Qty, Summ
где: Document_ID -номер документа OperationTypeID- тип операции(покупка,продажа,списание и т.п.)
AdrFromID, AdrToID откуда/куда делается операция (поставщик-склад, склад-склад, склад-клиент и т.п.)
Qty, Summ - знак в зависимости от операции - расход с минусом, приход с плюсом

Журнал промежуточных итогов (подИтогов):
TotalDate, ItemID, AdrID, Qty, Summ
где: TotalDate - дата на которую посчитан подИтог, AdrID - склад

Расчёт остатков - сумма ближайшего промежуточного итога и сумма операций по журналу по (дата) between (ближ.промеж.дата+1) and (нужная дата)
Использую union и агрегатную сумму по его результату :)
Промежуточные остатки можно делать, например 1-2 раза в месяц.
Применения между приходами и расходами (для парт.учёта) лежат в отдельной таблице, которую пока не будем рассматривать.
В любой момент базу можно урезать, но желательно по OperationDate не позднее самого раннего подИтога.
Наблюдается сильная зависимость производительности от удаленности даты до ближайшего подИтога
(если 2дня итог 2-3сек для 40тыс. товара, если 30дней, то 11-14 сек. Это всё для >4млн. операций за 10мес. сервер 2x2.4HHz 2Gb RAM)

Недостатки : невысокая производительность (частые Index Scan) :(
Вот собственно всё...
КТО КАК ЭТО ДАЛАЕТ ?
Есть подозрение, что сделать оптимальнее без потери функциональности не удастся.... :(
А ВАШЕ МНЕНИЕ ? :)
...
Рейтинг: 0 / 0
27.08.2004, 13:20
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32668792
Александр Спелицин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Спелицин
Участник
LSVНедостатки : невысокая производительность (частые Index Scan) :(
Разместите индексы и данные на разных винтах (не логических дисках одного харда).
А потом, частые Index Scan это лучше, чем Table Scan :).
...
Рейтинг: 0 / 0
27.08.2004, 13:26
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32668812
Ekuku
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ekuku
Участник
действительно вечная тема..
не надо функциональность трогать если у вас база MSSQL2000 или Oracle8-9
Сделайте разбиение физической таблицы
в Oracle - partition table или используйте materilized view (материал сами найдете в доках )
в MSSQL механизмы аналогичны ,но не помню точно как называются
В любом случае "общие" индексы можно "развязать" и сформировать более компактно в зависимости от стратегии разбиения таблиц..
(кстати, читайте форум Oracle)
...
Рейтинг: 0 / 0
27.08.2004, 13:31
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32668822
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
забыл добавить требование:
- необходимо получать данные одним запросом и желательно без подзапросов.

Это важно при получении отчетности внешними средствами. Может требование и необязательное, но желательное.
В описании желательно приводить временнЫе результаты Ваших решений ...типа как у меня... :)

2 Александр Спелицин
Речь идет не о повышении производительности конкретного сервера.
Нужно, чтоб структура работала пошустрее... :)
...
Рейтинг: 0 / 0
27.08.2004, 13:36
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32668829
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
самое главное опять забыл: MSSQL2000EE
хотя это не очень-то важно. Важно САМО РЕШЕНИЕ вне зависимости от платформы.
...
Рейтинг: 0 / 0
27.08.2004, 13:37
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32668849
Александр Спелицин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Спелицин
Участник
LSVИспользую union и агрегатную сумму по его результату :)
Union - это медленно. Попытайтесь от него уйти.
А насчет разнесения данных и индексов по разным дискам, советую подумать.
...
Рейтинг: 0 / 0
27.08.2004, 13:46
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32668869
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Серега
Участник
А почему нельзя хранить текущий остаток и пересчитывать его тригером. Тем более что все равно бОльшая часть запросов скорее всего на текущие остатки, а не на дату в прошлом.
...
Рейтинг: 0 / 0
27.08.2004, 13:55
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32668901
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
2 Александр Спелицин

Уйти ? Я бы с радостью.. А как ? Надо независимо просуммировать операции в двух таблицах и сложить полученные результаты. Причем в любой из них может не быть результата по нужным условиям (например когда "нужая дата"=ДатаПодИтога не будет данных в запросе по Товарному журналу).

также не вижу возможности использовать индексированные вью.... :)
Не помогут они, ИМХО...
Спасибо за советы по настройкам сервера, но это увы неактуально т.к. это не prodaction DB. Это пока development :)
А prodaction может работать и на простеньких серверах с простым IDE-зеркалом :) Например небольшой могазин.. :)
...
Рейтинг: 0 / 0
27.08.2004, 14:05
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32668927
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
автор бОльшая часть запросов скорее всего на текущие остатки
:) БОльшая это ещё не 100% :)

Кстати такая табличка есть... Она ещё резервирование товара показывает.
Правда меняется при проводке документа... Но это отдельный разговор.
важно иметь не просто остатки, но ещё и все (!) перемещения товара.
А вот перемещения смотрят постоянно и все кому не лень... :(
Для этого и товарный журнал с 4млн строк... :)
...
Рейтинг: 0 / 0
27.08.2004, 14:11
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32670484
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Серега
Участник
LSV:) БОльшая это ещё не 100% :)
Кстати такая табличка есть... Она ещё резервирование товара показывает.
Правда меняется при проводке документа... Но это отдельный разговор.
важно иметь не просто остатки, но ещё и все (!) перемещения товара.
А вот перемещения смотрят постоянно и все кому не лень... :(
Для этого и товарный журнал с 4млн строк... :)
Ну и что, что не 100%? Два запроса (две формы) на текущие остатки и на остатки на дату. Кстати, а зачем вообще нужны остатки на дату в прошлом? ИМХО, это как прошлогодний снег. И как связано желание всех смотреть на перемещения и остатки? Типа кол-во на начало периода->все перемещения->кол-во на конец периода? Ну сделать то можно, но какова актуальность этих данных и цена их получения? Имея журнал можно посчитать что угодно, вопрос зачем и как часто. Одно дело оперативный контур, где все должно летать, другое дело аналитика, где можно и подождать.
Все исключительно ИМХО.
Есть еще одна "маленькая" вкусность от хранения остатков - простой констрейнт на >=0 избавляет от минусовых остатков.
...
Рейтинг: 0 / 0
30.08.2004, 09:12
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32670703
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
2 Серега

:) Ну что сказать ?... Не знаком человек с розничной торговлей... :)
Перемещения товара смотрят часто и тут ничего не поделаешь...
Зачем нужны остатки на дату в прошлом ? Как это зачем ?
Например сверка с поставщиком на определённую дату, т.е. сколько оставалось его товара и сколько ему заплатить за уже проданое.
Не говоря уже про разборы полётов при оприходовании или отпуске ... :)
А констрейнтами не борятся с отрицательными остатками ! ! !
Потому, что есть ситуации когда отрицалово допустимо (в разумных пределах)
...
Рейтинг: 0 / 0
30.08.2004, 11:07
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32670744
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
распространенная ошибка это хранение типа опреации в журнале операции.
Тип операции должен однозначно определяться документом. Соответственно туда же (в документ) должны уйти дата операции, от кого и кому. Тогда работать будет значительно быстрее.

В журнале должны остаться только

Document_ID,
Item_ID,
Qty,
Summ

А в документе должны быть
ID,
OperationType, -- это определяется по типу документа
OperationDate,
AdrFromID,
AdrToID

В таком случае сначала однозначно по индексам определяется нужный список документов и затем это список джойнится с журналом. Попробуйте переделать и увидите как быстро все заработает. Проверено на практике. Удачи!
...
Рейтинг: 0 / 0
30.08.2004, 11:19
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32670752
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Серега
Участник
LSV:) Ну что сказать ?... Не знаком человек с розничной торговлей... :)

Ну да, конечно, где нам. 8-)

LSVЗачем нужны остатки на дату в прошлом ? Как это зачем ?
Например сверка с поставщиком на определённую дату, т.е. сколько оставалось его товара и сколько ему заплатить за уже проданое.
Не говоря уже про разборы полётов при оприходовании или отпуске ... :)

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

LSVА констрейнтами не борятся с отрицательными остатками ! ! !
Потому, что есть ситуации когда отрицалово допустимо (в разумных пределах)
А каков критерий "разумности" минуса? ИМХО - это бардак в организации просто. Вы в розничной торговле фьючерсами торгуете что ли.
...
Рейтинг: 0 / 0
30.08.2004, 11:20
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32670818
olk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olk
Участник
авторЯ и не говорю, что они не нужны совсем. Любую цифирь можно получить из журнала, а наличие всяких таблиц "остатков на дату" только усложняет логику запросов и пагубно влияет на производительность. Этот пункт спорный конечно, но это мое мнение.
Кхм ... дасс ... не смог утерпеть
это как же запрос типа
Код: plaintext
select qnty,summa from rest where articul= 11111  and dt='01.01.1998'

дольше чем что то типа
Код: plaintext
select sum(qnty),sum(summa) from opers where articul= 11111  and dt<= '01.01.1998'


авторА каков критерий "разумности" минуса? ИМХО - это бардак в организации просто. Вы в розничной торговле фьючерсами торгуете что ли.
да представте себе в розничной торговле тоже торгуют фьючерсами :))
т.е. обычная ситуация, когда собирают на отгрузку товар не поступивший на склад, но заказанный поставщику ....
...
Рейтинг: 0 / 0
30.08.2004, 11:49
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32670900
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Серега
Участник
olk[quot автор] это как же запрос типа
Код: plaintext
select qnty,summa from rest where articul= 11111  and dt='01.01.1998'

дольше чем что то типа
Код: plaintext
select sum(qnty),sum(summa) from opers where articul= 11111  and dt<= '01.01.1998'

И что? А на 2.01.1998 тоже сумма храниться будет? А на 3? И так на каждый день до сегодняшнего? А задним числом провели покупку? Все пересчитать?

olkда представте себе в розничной торговле тоже торгуют фьючерсами :))
т.е. обычная ситуация, когда собирают на отгрузку товар не поступивший на склад, но заказанный поставщику ....
Где собирают? Куда собирают? На складе?
...
Рейтинг: 0 / 0
30.08.2004, 12:15
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32670937
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
2 Old Nick

как раз хранение типа и даты операции в товарном журнале хоть и увеличивает размер таблицы, но заметно ускоряет запросы по статистике.
Намного ускоряет ! В разы ! Это тоже проверено !
Как можно в запросе делать ссылку на документы, если они разбросаны по разным таблицам ? Применять CASE ? Тогда наверняка будет Table scan.
Тем более для остатков тип документа как раз и не важен :) Важна сумма всех операций... :)
Повторю: Задача не только получить остатки на дату. Задача - получить универсальный функционал для работы с товаром.
Предложеное мной решение может и не оптимальное, но ИМХО наиболее близкое к желаемому...По крайней мере по функциональности...
...
Рейтинг: 0 / 0
30.08.2004, 12:29
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32670938
olk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olk
Участник
Серега olk это как же запрос типа
Код: plaintext
select qnty,summa from rest where articul= 11111  and dt='01.01.1998'

дольше чем что то типа
Код: plaintext
select sum(qnty),sum(summa) from opers where articul= 11111  and dt<= '01.01.1998'

И что? А на 2.01.1998 тоже сумма храниться будет? А на 3? И так на каждый день до сегодняшнего?


Можно и на каждый день ... что тут страшного ? ... можно хранить и "разреженный" остаток, т.е. по товарам по которым реально было движение ... запрос тогда немного усложниться, но работать будет все равно быстрее - чем пересчитывать по журналу операций с начала эксплуатации ...
Серега
А задним числом провели покупку? Все пересчитать?


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

olkда представте себе в розничной торговле тоже торгуют фьючерсами :))
т.е. обычная ситуация, когда собирают на отгрузку товар не поступивший на склад, но заказанный поставщику ....
СерегаГде собирают? Куда собирают? На складе?


Да на складе ... так как розница это не только продажи по магазинам, но и склад (причем в первую очередь), причем это я упростил (в "нормальном" складе, конечно кроме реального остатка существует и "фьючерский" и свободный (т.е. не зарезервированный" и т.д.)
кроме того есть такое понятие как пересортица, когда с до очередной инвентаризации приходиться мириться с отрицательными остатками ....
...
Рейтинг: 0 / 0
30.08.2004, 12:30
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32670988
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
2 Серега
>> Где собирают ? куда ? ....

Например скоропорт может быть продан раньше, чем оприходуют. И эта разница может составлять во времени всего полчаса... :)
Часто приходуют утром вечерние поставки, а товар уже почти продан :)
Не надо рассказывать про бардак ! Он в рознице неизбежен, хотя масштабы его должны быть незначительны. :) :) :)

Кстати полностью согласен с olk ! Понимает человек, о чём идёт речь ! ! !
...
Рейтинг: 0 / 0
30.08.2004, 12:47
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32670996
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Серега
Участник
olkМожно и на каждый день ... что тут страшного ?
Да так ерунда - 10000 товаров, на каждый день остаток, ну разрежено на 5000 в день. А когда ксьати считать то "за день"? Вечером? А если кладовщик полуношник после подсчета отгрузил что нибудь?

olkзапрос тогда немного усложниться, но работать будет все равно быстрее - чем пересчитывать по журналу операций с начала эксплуатации ...

Почему с начала эксплуатации? С текущего момента.
...
Рейтинг: 0 / 0
30.08.2004, 12:50
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32671056
olk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olk
Участник
Серега olkМожно и на каждый день ... что тут страшного ?
Да так ерунда - 10000 товаров, на каждый день остаток, ну разрежено на 5000 в день. А когда ксьати считать то "за день"? Вечером? А если кладовщик полуношник после подсчета отгрузил что нибудь?

olkзапрос тогда немного усложниться, но работать будет все равно быстрее - чем пересчитывать по журналу операций с начала эксплуатации ...


Почему с начала эксплуатации? С текущего момента.
Ну это уже спор ради спора
Да хоть 50000 поверте на слово это такой мизер, по сранению с остальным объемом информации ....
Согласен - что это некоторая денормализация базы , но что то я никогда
не был особым сторонником Клода
Ну нравится ... пересчитывайте по журналу, я просто выразил свое мнение ...
кстати подтвержденное некоторым опытом ...

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

А что в вашем тогда понимании "текущего" , т.е. я так понимаю
что есть текущий остаток (кстати на какой момент ?) и если мы хотим получить остаток за предыдущий день то выбираем документы предшествующие этому "текущему" моменту и по ним расчитываем ? (кстати а до какого момента выбираем ? до какого часа , минуты ) ... это я так стебусь , возвращая вам ваши же вопросы
...
Рейтинг: 0 / 0
30.08.2004, 13:12
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32671142
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Серега
Участник
olk
А что в вашем тогда понимании "текущего" , т.е. я так понимаю
что есть текущий остаток (кстати на какой момент ?)
На момент фиксации транзакции.

olk
и если мы хотим получить остаток за предыдущий день то выбираем документы предшествующие этому "текущему" моменту и по ним расчитываем ?
Берем текущий остаток и "откатываем" нужные документы. Все то же самое, но с другой стороны. 8-)
...
Рейтинг: 0 / 0
30.08.2004, 13:35
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32671613
Фотография vma_mnt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vma_mnt
Участник
Я всегда за динамический подсчет остатков. IMHO это наиболее безпроблемный путь при правке документов задним числом и избавляет от всяких неучтенных проколов.

Делается так:

INSERT INTO #TABLE1 (ОстатокПоТовару, Метка) SELECT SUM(КолТовара), 0 FROM ПриходТовара WHERE Дата < @Дата

INSERT INTO #TABLE1 (ОстатокПоТовару, Метка) SELECT -SUM(КолТовара), 0 FROM РасходТовара WHERE Дата < @Дата

INSERT INTO #TABLE1 (ОстатокПоТовару, Метка) SELECT SUM(КолТовара), 1 FROM #TABLE1

DELETE FROM #TABLE1 WHERE Метка = 0

Пользователи не замечают, что при открытии формы остатков они считаются динамически.

Пример приведен упрощенно, все суммы типа Количество*Цена считаются триггерами и заносятся в соответствующие поля. То есть в приведенных выше запросов никаких расчетов не делается.
...
Рейтинг: 0 / 0
30.08.2004, 16:05
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32671657
Dedushka Mazai
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dedushka Mazai
Участник
авторэто наиболее безпроблемный путь при правке документов задним числом и избавляет от всяких неучтенных проколов
не избавляет - дублирование информации приводит к потенциальным ошибкам. В этом случае процедуру пересчёта нужно откатать от и до. малейшая погрешность или какой-нибудь неучтённый нюанс - и сумма по таблице(ам) с оборотами не будет соответствовать рассчитанным остаткам. Плюс надо протестировать это дело на миллионных таблицах, а то при накоплении истории по оборотам каждый следующий пересчёт можно некисло тормозить работу
...
Рейтинг: 0 / 0
30.08.2004, 16:18
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32671759
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
LSV2 Old Nick

как раз хранение типа и даты операции в товарном журнале хоть и увеличивает размер таблицы, но заметно ускоряет запросы по статистике.
Намного ускоряет ! В разы ! Это тоже проверено !
Как можно в запросе делать ссылку на документы, если они разбросаны по разным таблицам ? Применять CASE ? Тогда наверняка будет Table scan.
Тем более для остатков тип документа как раз и не важен :) Важна сумма всех операций... :)
Повторю: Задача не только получить остатки на дату. Задача - получить универсальный функционал для работы с товаром.
Предложеное мной решение может и не оптимальное, но ИМХО наиболее близкое к желаемому...По крайней мере по функциональности...

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

Расходная и приходная накладная сильно различаются по структуре? А заказ от них сильно отличается? Применяйте наследование и будет вам счастье. Если не знаете что это такое применительно к базе вспомните про маппирование классов на базу данных.

Каждый класс соответствует своей таблице. Например, абстрактная накладная - это таблица ANakl и в ней поля тип, дата, от кого и кому, наследники расходная накладная и приходная накладная отличаются только типом, в таком случае своих таблиц не имеют, а имеют записи в таблице ANakl, но с соответствующим значением в поле тип.
...
Рейтинг: 0 / 0
30.08.2004, 16:45
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32671795
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Что-то в топике почти нет конструктивных советов и своих примеров решения затронутой проблемы... :(
Все хранят свои тайны ? ? ?
Зато желающих похаять что-либо или вставить свои 5коп. не в тему (зарисоваться) хоть отбавляй... :(
Опять забыли, что обсуждаем и перешли на личности ? Несолидно, коллеги ! ! !

ВОПРОС И УСЛОВИЯ ПОСТАВЛЕНЫ ОЧЕНЬ ЧЁТКО.
Просьба приводить ТОЛЬКО ПРОВЕРЕННЫЕ РЕШЕНИЯ И ТОЛЬКО ЕСЛИ ВЫПОЛНЯЕТСЯ ХОТЯ-БЫ БОЛЬШАЯ ЧАСТЬ НАЧАЛЬНЫХ УСЛОВИЙ !
...
Рейтинг: 0 / 0
30.08.2004, 16:56
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32671890
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
2 Old Nick

Отчасти согласен, но если вести все документы в двух таблицах (шапка/строки) то и товарный журнал не нужен... :)
Но ведь все серьёзные системы имеют его. И документы обычно в разных таблицах хранятся.
Общие таблицы это палка о двух концах... Затрудняюсь сказать, где больше преимуществ. Наверно поровну... :)

Начать что ли новый топик про "Общие таблицы документов" ? ? ? :)

Качественно спроектированый журнал не требует хранение документов в общих таблицах, ИМХО...
...
Рейтинг: 0 / 0
30.08.2004, 17:24
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32671922
Dedushka Mazai
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dedushka Mazai
Участник
согласись, что есть разница строить ли запросы по одной таблице или по N таблицам.

авторКачественно спроектированый журнал не требует хранение документов в общих таблицах, ИМХО...
если все документы однотипные и пересекаются, то хранение их в одной таблице заметно упрощает разработку
...
Рейтинг: 0 / 0
30.08.2004, 17:33
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32671980
olk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olk
Участник
LSV2 Old Nick

Отчасти согласен, но если вести все документы в двух таблицах (шапка/строки) то и товарный журнал не нужен... :)
Но ведь все серьёзные системы имеют его. И документы обычно в разных таблицах хранятся.
Общие таблицы это палка о двух концах... Затрудняюсь сказать, где больше преимуществ. Наверно поровну... :)

Начать что ли новый топик про "Общие таблицы документов" ? ? ? :)

Качественно спроектированый журнал не требует хранение документов в общих таблицах, ИМХО...
Ну если нужна конкретика то пожалуйста

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


алгоритм примерно такой (сильно упрощенный)
1. Штатная ситуация
при закрытии документа до статуса факт, текущей датой (по идее дальше документ изменяться не должен ... но об этом позже) через тригер, заполняется (пересчитывается) реестр остатков , в самом документе проставляется ометка, что он отражен в реестре
таким образом автоматически получаем "разреженный" реестр остатков на текущий момент ...
2. Нештатная ситуация № 1 (удаление (ануляция) уже зафиксированного документа) - примерно то же самое, тригером пересчитывается текущий остаток + все остатки затронутые этим документов от текущей даты до даты
изменения статуса до факта
3. Нештатная ситуация № 2 (коррекция уже зафиксированного документа) - примерно то же самое, тригером пересчитывается текущий остаток + все остатки затронутые измененными строками документов от текущей даты до даты изменения статуса до факта
4. Нештатная ситуация № 3 (добовление (и закрытие) документа задним числом) - то же самое, тригером пересчитывается текущий остаток + все остатки затронутые документом от даты факта до текущей
5. Нештатная ситуация № 3 (изменение (возврат) статуса документа) - то же самое, тригером пересчитывается текущий остаток + все остатки затронутые документом от даты факта до текущей, снимается отметка с документо об отражении в реестре ...

таким образом в любой момент времени, имеем актуальный реестр остатков

Дополнительно предусмотрена процедура проверки и коррекции реестров
(т.е. пересчет за любой заданный период по документам) - запусается джобом по выходным
...
Рейтинг: 0 / 0
30.08.2004, 17:50
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32672123
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
LSV 2 Old Nick

Отчасти согласен, но если вести все документы в двух таблицах (шапка/строки) то и товарный журнал не нужен... :)
Но ведь все серьёзные системы имеют его. И документы обычно в разных таблицах хранятся.
Общие таблицы это палка о двух концах... Затрудняюсь сказать, где больше преимуществ. Наверно поровну... :)

Начать что ли новый топик про "Общие таблицы документов" ? ? ? :)

Качественно спроектированый журнал не требует хранение документов в общих таблицах, ИМХО...

Именно такой подход использовался при разработке ЕРП системы Ontario System 2.0

Базовым класс системы "Абстрактный объект БД", и находится в таблице Objs, все наследники (а это все справочники, все документы и куча других настроечных объектов) соответственно имеют запись в этой таблице.
Объектов в таблице более 500 000. В матрице прав записей не менее 2 миллионов.
Щелкнув на клиенте правой кнопкой мыши по объекту можно получить контекстное меню с доступными операциями над объектом, при этом проверяются все права пользователя на объект (таблица 2 миллиона записей). Меню открывается мгновенно.
Многострочная часть всех документов, которые таковую имеют находится в одной таблице (как вы говорите и журнал не нужен), записей там несколько миллионов. Остатки на складе считаются селектом с суммированием по приходным и расходным документам с отслеживанием их состояния. Все это на лету. Время отклика несколько секунд.

Что это за система можно посмотреть на сайте Краткий обзор предлагаемых на рынке программного обеспечения систем
...
Рейтинг: 0 / 0
30.08.2004, 18:43
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32672183
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
2 Old Nick

Информация про Онтарио интересная, хотя мало подробностей про производительность. Несколько секунд это на каком сервере и для какого кол-ва товаров ? Если несколько секунд для одного товара, то это ужас... :)
Кстати а как насчёт вести учет в разных ед.измерения ?
Например Приход в тоннах, расход в литрах (топливо).
При суммировании придётся тормознуто пересчитывать... :)

Сколько у Вас полей в строчной части ?
У меня в журнале всего 11 полей.
для 4млн.строк по 40тыс.товара считает примерно 13-18 сек на 2х2.4ГГц 2Г ОЗУ. Таблица занимает примерно 800МБ с индексами.
Запрос только по одной таблице. Без промежуточных итогов.
Неужели у вас считает быстрее ? ? ? Если да, то каким образом ? ? ?
...
Рейтинг: 0 / 0
30.08.2004, 19:29
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32672235
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
На какой адрес можно отправить полную доку?
...
Рейтинг: 0 / 0
30.08.2004, 20:04
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32672590
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Адрес есть в моём профиле.
За возможность почитать доку большое спасибо ! ! !
Уверен, что будет очень интересно.
...
Рейтинг: 0 / 0
31.08.2004, 10:02
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32685290
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Пропал интерес к топику ? :(
Никто не хочет ничего добавить ?
Ни у кого нет ценного опыта по Subj ? ? ? :)
Будет также интересен опыт по западным ERP-системам.
...
Рейтинг: 0 / 0
08.09.2004, 13:38
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32685917
TimKa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TimKa
Участник
Попробуйте уйти от хранения промежуточных остатков в отдельной таблице, а храните их в той же, что и движение, со специальным признаком. Таким образом уйдете от юниона, и производительность возрастет.

Так же советую все же приход записывать в одну колонку а расход в другую, по типу дебета-кредита - таким образом всегда можно понять сколько куда ушло, включая внутренний оборот между складами, но это уже удобства.
...
Рейтинг: 0 / 0
08.09.2004, 17:17
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32685920
TimKa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TimKa
Участник
LSV2 Old Nick

Начать что ли новый топик про "Общие таблицы документов" ? ? ? :)

Качественно спроектированый журнал не требует хранение документов в общих таблицах, ИМХО...

Такой топик уже был, "одна или много таблиц" назывался.
...
Рейтинг: 0 / 0
08.09.2004, 17:18
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32686902
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
2 TimKa
Пробовал... Пока не получилось т.к. сложно отбросить посторонние сальдовые записи из обрабатываемого периода.
например:
01.01.04 сальдо 5 шт
02.01.04 продажа 1шт
03.01.04 покупка 2шт
04.01.04 сальдо 5-1+2=6шт
05.01.04 продажа 4шт.
как использовать запись 01.01.04 и не использовать 04.01.04 для периода 01.01.04...05.01.04 ????
процедура отброски лишних промежуточных сальдо получается неоптимальной.
В итоге выигрыша нет.... :(

Кстати юнион должен неплохо выполняться на 2процессорном сервере ИМХО...
...
Рейтинг: 0 / 0
09.09.2004, 11:32
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32686945
Прохожий2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Прохожий2
Гость
LSV...как использовать запись 01.01.04 и не использовать 04.01.04 для периода 01.01.04...05.01.04 ????
Безотносительно к правильности/неправильности подхода:
? ~where дата between 01.01.. 05.01.. and (Опер<>'сальдо' OR дата=01.01.04) ?
...
Рейтинг: 0 / 0
09.09.2004, 11:41
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32687046
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Прохожий2 ~where дата between 01.01.. 05.01.. and (Опер<>'сальдо' OR дата=01.01.04)
Примерно так и делал, но такая вот конструкция не использует индексы... :)
Надо стараться избегать OR и <>. А тут они обе... :)
Поэтому выигрыша не получилось . . . :(
В любом случае спасибо за совет. Может у кого-то есть ещё мысли ?
...
Рейтинг: 0 / 0
09.09.2004, 12:15
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32687191
TimKa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TimKa
Участник
Есть Акт Инвентаризации - по нему строим проводку сальдо на дату. Реальной инвентаризации может и не быть конечно. Но даты у вас этих актов есть и их можно получить из актов с полпинка, так же как и номер документа @id_saldo.

Далее выбираем все движение по складe doctype in (расход, приход) or (doctype=сальдо AND id=@id_saldo) и по соотв датам.

Не верю что это медленнее чем юнион.

Подразумевается. что в регистре движения есть поля тип документа и Id документа, по которому произведена проводка и они проиндексированы...
...
Рейтинг: 0 / 0
09.09.2004, 12:53
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32687439
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
Я не говорил, что медленнее ! Просто результат примерно одинаковый за счёт плохой обработки "OR" и "<>".
...
Рейтинг: 0 / 0
09.09.2004, 14:03
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32687564
TimKa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TimKa
Участник
LSVЯ не говорил, что медленнее ! Просто результат примерно одинаковый за счёт плохой обработки "OR" и "<>".

Хм ну от <> избавится легко - не исключать промежуточные сальдо, а включить все, кроме них

Кстати если ввести составной индекс по двум полям doctype и id, то и (doctype=сальдо AND id=@id_saldo) думаю будет работать быстрее.
...
Рейтинг: 0 / 0
09.09.2004, 14:39
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32687643
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
TimKaХм ну от <> избавится легко - не исключать промежуточные сальдо, а включить все, кроме них
Оптимизатору это наверняка одно и то же..... :) Перечисления оптимизатор тоже не любит. :(
Кстати Вы рекомендуете теоретически или есть реальный проект с такой реализацией ? Интересуют цифры производительности... :)
Мои цифры Вы уже видели.
...
Рейтинг: 0 / 0
09.09.2004, 14:54
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32688697
TimKa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TimKa
Участник
LSVИнтересуют цифры производительности... :)
Мои цифры Вы уже видели.

Да, проект был, но сейчас уж и не знаю где он :) И конторы-заказчика, и производителя уже нет.
...
Рейтинг: 0 / 0
10.09.2004, 07:24
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32690668
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
LSV. Моя база. Производственный склад.
Промежуточных сальдо нет, но есть таблица текущих остатков, которая обновляется в единой транзакции при приходе-расходе в таблице журнала операций. Типов документов - два. Приход и расход. Определяются знаком в поле количество. Минус - расход, плюс - приход. Таким образом, салдо на любую дату вычисляется простым суммированием по полю. Конкретика документа: расход на производство, списание от порчи, межскладское перемещение и т.д. и т.п. определятся счетом+субсчетом+статьей (одно поле, но можно было бы и три сделать. Просто в организации принято писать все это в одно слово).

Первичный индекс в журнале операций - склад, дата, номер документа, номенклатурный номер, цена.

Другие индексы -
Склад, номер.
Счет+субсчет+статья, Дата
Номер.

Крутится на P-350 128 RAM. MS SQL 2000. В журнале операций около 300 000 записей.
Вычисление сальдо по одному номеру - менее 1 сек.
Вычисление сальдо по счетам - около 30 сек.
Пересчет остатков суммированием "от сотворения мира"- около 10 сек.

=========
Примерно так же устроена и моя база в торговом оптовом складе. С одним маленьким НО. Заказчик хотел, что бы никто и никогда не мог вычислить, сколько товара РЕАЛЬНО было принято. Поэтому в базе операции прихода нет вообще. Для внутренних нужд приход считается, как текущие остатки+расход. Оприходывание товара происходит занесеним в таблицу остатков. Как он там разбирается с поставщиками - не мои проблемы.

Про производительность ничего сказать не могу. Не знаю, на каком железе она крутится сейчас :). База на клипере, написана 1993 году. Заказчик до сих пор на ней работает. Раз в год звонит, поздравляет с Новым годом.
...
Рейтинг: 0 / 0
11.09.2004, 15:56
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32708772
Vladimir_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir_
Участник
просто заебэ
читаю и читаю как песню. может я конечно что-то пропустил. но как одним запросом получить остатки используя всего одну дату. да НИКАК. на таблице в 4000000 записей и более считать сумму входящих остатков, которые уже давно ушли? я для этих целей веду табличку где хранятся две даты: дата начала периода и дата окончания интервала и остаток на этом интервале и склад. И можно получить одним запросом остатки на любую дату и по любому складу и хоть по всем складам ОДНИМ запросом. Да еще и табличка построена по index organisation (не помню точно как пишется). Но срез на любую дату получается очень быстро. Да и остатки можно вести нескольких типов. опять таки и реальные и с учётом резерва и ... получаются одним запросом.
...
Рейтинг: 0 / 0
23.09.2004, 15:34
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32709864
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
2 Vladimir_
>> Да никак !
Что "никак" ? Имелось ввиду, что у запроса одно внешнее условие (ДАТА)
Оно может прописываться хоть в десять мест в теле запроса, который может содержать union или подзапросы. И кстати Вы организовали примерно как же как и я... :)
...
Рейтинг: 0 / 0
24.09.2004, 10:55
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32771643
AlbertG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlbertG
Гость
Мы используем хранение остатков на дату изменения,
таким образом отличие от приведенного вначале примера
- наличие еще одного поля DATE_SALDO_NEXT

тогда выборка остатков на любую дату :

select SALDO
from STORE_SALDO
where DATE_SALDO >= :DATE
and DATE_SALDO_NEXT > :DATE
and ID_STORE = :ID_STORE
and TOVAR = :TOVAR

минусы
усложненность вставки и модификации (процедуры)
различные мнококолоночные индексы по таблице

плюсы
очевидны
...
Рейтинг: 0 / 0
06.11.2004, 10:09
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32771644
AlbertG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlbertG
Гость
AlbertGМы используем хранение остатков на дату изменения,
таким образом отличие от приведенного вначале примера
- наличие еще одного поля DATE_SALDO_NEXT

тогда выборка остатков на любую дату :

select SALDO
from STORE_SALDO
where DATE_SALDO >= :DATE
and DATE_SALDO_NEXT > :DATE
and ID_STORE = :ID_STORE
and TOVAR = :TOVAR

минусы
усложненность вставки и модификации (процедуры)
различные мнококолоночные индексы по таблице

плюсы
очевидны

точнее так:

select SALDO
from STORE_SALDO
where DATE_SALDO <= :DATE
and DATE_SALDO_NEXT > :DATE
and ID_STORE = :ID_STORE
and TOVAR = :TOVAR
...
Рейтинг: 0 / 0
06.11.2004, 10:10
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32771702
Фотография Andrey K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey K
Участник
На любом складе минимум два раза в год проходит плановая нивентаризация. При этом положительные и отрицательные остатки по партиям ("пакетам") товаров будут возникать в любом случае если их приёмка (отгрузка) связана с применением приборов имеющих измерительные погрешности. (Справедливо для любых товаров нештучного учёта). В процессе инвентаризации производят сопоставление фактического наличия товара на складе с предполагаемым расчётным количеством в виртуальном складе. Для нулевых фактических остатков на реальном складе (можно и для не нулевых) остатки виртуального склада анализируются в соответствии с количеством измерений (отргузок-приёмок) если остаток положительный и болше чем количество измерений * максимальную погрешность измерительного прибора - то налицо факт воровства. если остаток положительный то обычно торговали "хорошо" наё;№ли клиентов вопросы могут возникнуть только у налоговой в соответствии с той же формулой (если больше допустимого - это мошенничество).

Все данные для данного анализа есть в пинципе в БД нужно только в профиле склада указать погрешности измерений ;) => и автоматически выявлять отклонения от нормы

Так вот в любом случае генерируются соответствующие складские (и не только) документы которые должны быть оражены в БД (помимо элементарных приходных и расходных накладных - которых в свою очередь тоже может быть несколько видов) :)

При регистрации, докумена который отражает собой собственно факт инвентаризации (форма № МХ-19) нужно для каждогой партии ("пакета") откоректировать значение остатка! Если фактически он "нулевой" присвоить статус пакету => учитывать этот статус при выборке текущих остатков :)
Это усложнит вашу задачу складского учёта, но система в целом будет написана более грамотно. (вам придётся пересмотреть структуру БД вцелом... перечень возможных документов) Проблема со скоростью выборки текущих остатков будет решена.

Неполный перечень документов которые должны учитыватся в складском учёте.

По поводу использования регистров и технологии используемой в 1С я уже высказывал своё скромное мнение.

Можно предусмореть процедуру усечения устаревших данных (сохранеием их в архив, без всяких промежуточных регистров)...
это очень сложная задача
...
Рейтинг: 0 / 0
06.11.2004, 13:28
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32771913
Фотография Andrey K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey K
Участник
Andrey K
Проблема со скоростью выборки текущих остатков будет решена.

Хочу уточнить. При установке фактического "нулевого" статуса для партии (пакета) товаров. (факт должен выявляться в процессе инвентаризации, и регистрироваться в БД с оформлением соответствующих документов для каждой партии (пакета) товара!). Строки с таким статусом выностить в отдельную таблицу ("таблицу истории") с аналогичной структурой.

Для анализа сальдо и остатков по предыдущим периодам использовать уже UNION. (скорость для таких операций не так критична, как для получения текущих остатков - потому что такие операции выполняются гораздо реже)
...
Рейтинг: 0 / 0
07.11.2004, 11:57
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32775816
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dmitry Biryukov
Участник
Проработав некоторое время с ОЛАП-ом могу предложить такой подход.

Время представляем как иерархию год-месяц-день. (можно и по другому, тогда доп. таблицы будут другие) создаём 3 доп. таблицы:

"движение по годам" - товар, год, "сумма приходов и расходов за год"
"движение по месяцам" - товар, год, месяц, "сумма за месяц"
"движение по дням" - товар, год, месяц, день, "сумма за день"

Тогда при проведении документа надо будет тригером изменить всего лишь 3 числа - по одному в каждой из указанных выше таблиц

Для получения остатка на любую дату надо будет сложить всего лишь несколько чисел:
1 - по предшествующим годам таблицы 1 (пусть в среднем 5 таких чисел)
2 - по предшествующим месяцам таблицы 2 (пусть в среднем 6 чисел)
3 - по предшествующим дням таблицы 3 (пусть в среднем 15 чисел)

итого:
редактирование - 3 операции
подсчёт остатков - 26 операций

Есть варианты быстрее?
...
Рейтинг: 0 / 0
10.11.2004, 15:57
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32775862
Dmitry Biryukov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dmitry Biryukov
Участник
Дальше возможны вариации и различный баланс между временем пересчёта движений и временем получения остатков:
Вариация с уменьшением времени расчёта остатков (увеличивается время проведения док-та)
сделать таблицы "группа годов"-"год"-"полугодие"-"месяц"-"неделя"-"день"

тогда при проведении документа 6 операций
при расчёте остатков в среднем 1+2+1+3+2+3 = 12 операций

(даже в сумме выйграли: было 29, стало 18. хотя может я не так усреднил)

Вторая вариация в сторону уменьшения времени проведения документа (увеличивается время расчёта остатков)
"кварталы всех годов"-"дни кварталов"
проведение 2 операции
расчёт в среднем 10+60 = 70 операций

вырожденными(крайними) случаями применения этого подхода являются уже упомянутые участниками выше:
1. без доп. таблиц. При проведении ничего считать не надо, при расчёте остатка - несколько тысяч (сотен тысяч)
2. доп таблица с остатками на каждую дату. При проведении - очень длинный расчёт (по всем дням, которые позже даты документа). Расчёт остатков - мгновенно - одно число.

Лучший выход, как известно, - золотая середина :-)
...
Рейтинг: 0 / 0
10.11.2004, 16:16
| Ответить | Цитировать | Написать  
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32776348
Фотография UK0IAI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
UK0IAI
Участник
Расчёт остатков - сумма ближайшего промежуточного итога и сумма операций по журналу по (дата) between (ближ.промеж.дата+1) and (нужная дата)
Использую union и агрегатную сумму по его результату :)
Промежуточные остатки можно делать, например 1-2 раза в месяц.

как вариант - вот такой запрос

Код: plaintext
1.
2.
3.
4.
select ItemID, 
        Data_doc, 
        sum(Qty * Знак_приход_расход) 
from  Товарный журнал
group by ItemID, Data_doc

Такой запрос - когда дата приходного расходного дока - в group by ItemID, Data_doc - на автомате сам считает остаток ....на любую дату "движения товара". Только вот даты здесь - как бы не все...а только, те что были реально...

Такую фичу я бы сохранил в оракле в MV. и потот юзал ее - уже изучая остатки по артикулам и по датам.
...
Рейтинг: 0 / 0
10.11.2004, 20:17
| Ответить | Цитировать | Написать  
53 сообщений из 53, показаны все 3 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / И снова про СКЛАДСКИЕ ОСТАТКИ...
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]