powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / И снова про СКЛАДСКИЕ ОСТАТКИ...
25 сообщений из 53, страница 2 из 3
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32671890
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Old Nick

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про производительность ничего сказать не могу. Не знаю, на каком железе она крутится сейчас :). База на клипере, написана 1993 году. Заказчик до сих пор на ней работает. Раз в год звонит, поздравляет с Новым годом.
...
Рейтинг: 0 / 0
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32708772
Vladimir_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
просто заебэ
читаю и читаю как песню. может я конечно что-то пропустил. но как одним запросом получить остатки используя всего одну дату. да НИКАК. на таблице в 4000000 записей и более считать сумму входящих остатков, которые уже давно ушли? я для этих целей веду табличку где хранятся две даты: дата начала периода и дата окончания интервала и остаток на этом интервале и склад. И можно получить одним запросом остатки на любую дату и по любому складу и хоть по всем складам ОДНИМ запросом. Да еще и табличка построена по index organisation (не помню точно как пишется). Но срез на любую дату получается очень быстро. Да и остатки можно вести нескольких типов. опять таки и реальные и с учётом резерва и ... получаются одним запросом.
...
Рейтинг: 0 / 0
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32709864
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Vladimir_
>> Да никак !
Что "никак" ? Имелось ввиду, что у запроса одно внешнее условие (ДАТА)
Оно может прописываться хоть в десять мест в теле запроса, который может содержать union или подзапросы. И кстати Вы организовали примерно как же как и я... :)
...
Рейтинг: 0 / 0
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32771643
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
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32771644
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
И снова про СКЛАДСКИЕ ОСТАТКИ...
    #32771702
Фотография Andrey K
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На любом складе минимум два раза в год проходит плановая нивентаризация. При этом положительные и отрицательные остатки по партиям ("пакетам") товаров будут возникать в любом случае если их приёмка (отгрузка) связана с применением приборов имеющих измерительные погрешности. (Справедливо для любых товаров нештучного учёта). В процессе инвентаризации производят сопоставление фактического наличия товара на складе с предполагаемым расчётным количеством в виртуальном складе. Для нулевых фактических остатков на реальном складе (можно и для не нулевых) остатки виртуального склада анализируются в соответствии с количеством измерений (отргузок-приёмок) если остаток положительный и болше чем количество измерений * максимальную погрешность измерительного прибора - то налицо факт воровства. если остаток положительный то обычно торговали "хорошо" наё;№ли клиентов вопросы могут возникнуть только у налоговой в соответствии с той же формулой (если больше допустимого - это мошенничество).

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

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

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

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

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

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

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

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


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