Pull to refresh

Comments 10

Почему не организовать простую таблицу типа «Регистр», в которой будут основные поля «Дата движения в регистре», «Тип движения» (приход/расход/перемещение/возврат и т.д.), «Кол-во» — или другие в зависимости от типа регистра? А как дополнение через разрез IDExternalType + IDExternalObject джоинить все что душе угодно — различные характеристики субъекта движения и все остальное? Универсальный регистр, такие модели давно существуют — та же 1С
Данная таблица по вашему и есть «регистр», мы храним в нем дату, тип движения, остатки.

Для работы склада не важны тип движения. Для хранения «бумажной документации», используются дополнительные таблицы, которые ссылаются на историю движения деталей.

В подобном же подходе можно удалять или переносить все записи с одним SPI у которых сумма по QtyRest = 0, поскольку это уже история.

Универсально тем плохо тем, что реализуется быстро и сносно работает на небольшом количестве данных.
универсальность бьёт по производительности.

например, если перемещения в 99% случаев делаются парами (из SRC ушло, в DST пришло), то нужно делать две записи, и для их связи заводить поле «код транзакции»

в задачах типа «посчитать внешнюю активность» (все движения, где SRC и DST относятся к разным подразделениям) удобнее использовать схему, где SRC и DST хранятся в одной записи
Вот смотрю на дизайн старых приложений и наступает уныние…
К сожалению отдельного дизайнера у проекта не было.
Проект на WindowsForms, но всегда есть возможность сделать красивую мордочку, поскольку MVP.
Насколько я помню, дизайн был создан в тесном сотрудничестве с логистами.
Часами с ними сидели и страдали над юзабилити, на эстетику никто не смотрел.
Да я больше не про это приложение, я про себя. Избаловали меня хорошим простым дизайном без большого кол-ва визуального шума.
Причем колёса конкрэтно восьмиугольные…
А можно услышать более развернутый ответ?
Sign up to leave a comment.

Articles