Здравствуйте, А.М, Вы писали:

А.М>Почему нет? NoSQL пока может еще и сыроваты, но прогресс не стоит на месте.
А разве реализации nosql поддерживает ACID в полном объеме?

Здравствуйте, ronaldo9, Вы писали:

R>Здравствуйте.

R>У меня вопрос по проектированию модели данных для складов. Общие требования к разрабатываемой системе такие:
R>1. Есть несколько складов. На складе располагаются товары.
R>2. Есть операции приемки товара на склад, перемещения на другой склад и списания со склада.
R>3. Необходима возможность просмотреть прошлое состояние склада (ограничение, например, за год)
R>4. Необходимо хранить данные по прошедшим операциям.
R>5. Необходима возможность отмены и изменения прошедшей операции приемки/перемещения/списания.
R>6. Прошедшие операции следует хранить не более 1 года.

R>Какой подход избрать для проектирования модели данных?

R>У меня в голове сейчас 3 варианта.

R>1 вариант. Не хранить, сколько товара было на складе в каждый конкретный момент. Хранить только операции, например:

R>Тогда мы можем агрегировать эти операции по складу и товару

1) Хранить только операции и агрегировать (например через индексированные/материализованные представления, ну или собственным велосипедом) тоже только операции, а не остатки (существенно меньше пересчета в случае отмены операции и по теории РБД более правильно)
2) операцию перемещения желательно хранить одним кортежем причем в той же таблице что и приход расход (проще расчеты и меньше возможных ошибок). Что-то типа Источник (склад или null если приход), Приёмник (склад или null если списание), Товар, Количество.
3) во временной таблице или где-то в слое бизнес логики возможно полезно будет хранить актуальные остатки на текущий момент (а интерфейс к этой таблице тот же что и для "прошлых состояний", просто текущее состояние будет отображаться гораздо быстрее, а я уверен именно его и будут запрашивать в 99% случаев)

4) если "не хранить операции старше года" жёсткое требование, тогда за давние периоды хранить только агрегаты. В этом случае скорее всего свой "велосипед" для агрегации придется делать или заменять старые движения агрегированными движениями прямо в рабочей таблице. Но я бы хранил всю историю.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Poudy, Вы писали:

P>>RDBMS подход хорош только в первом приближении. В пределе заводим единую таблицу проводок, в которой у нас лежат все значения в разрезе по всем возможным координатам, в которой храним как 1) "реальные данные" (данные реальных счетов), т.е. как оно заводится "в документах", так и переносим — без агрегации или разбиения, — так и 2) разные "нереальные данные" (данные синтетических счетов) — разбиения и группировки, частичные остатки и прочую муть для нужд практического учета и быстрых отчетов. Конечно, прямые реальные остатки будут храниться верно и выбираться просто, но все агрегации и расчеты на основе агрегаций будет уже писать человек! Причем ладно бы это были только обороты за период, где ошибиться трудно. Это будут синтетические проводки по разным галочкам в карточке товара, в карточке контрагента и в шапке документа, которые, если там еще история завязана, может пересчитываться неадекватно, а уж если какое значение в отчете зависит от суммы/разницы таких вот значений, то там точно также легко наваять неверную формулу расчета — забыли что-то прибавить или вычесть, или еще хуже, обнаружили в конце концов, что на основе этих значений посчитать нельзя и нужны другие синтетические счета.

G>Не надо смешивать все в одну кучу. Одно дело аналитически отчеты по проводкам (баланс и все такое), другое дело документооборот, который должен в идеале делаться отдельно от самой бухгалтерии и нужно иметь слой отображения документов на проводки.

Сорри за задержку — почему-то на почту не ходят ответы. Я полностью согласен — не надо ничего смешивать. Бухгалтерия тут не при чем, я говорил о складских проводках. Ведь строки документов склада тоже не надо мешать в кучу с остатками, а иметь отдельные складские проводки для склада, правда же? Да ты и сам об этом писал, что я. Не знаю, мне кажется я всё понятно очень написал, откуда ты вычитал баланс не знаю... Покупайте облигации обязательного займа!

Здравствуйте, Poudy, Вы писали:

P>Бухгалтерия тут не при чем, я говорил о складских проводках.
А склад остатки уже не является объектом бухгалтерского учета?

P>Ведь строки документов склада тоже не надо мешать в кучу с остатками, а иметь отдельные складские проводки для склада, правда же?
Чето не понял что от чего предполагается отделять и зачем.

Здравствуйте, ronaldo9, Вы писали:

R>У меня вопрос по проектированию модели данных для складов. Общие требования к разрабатываемой системе такие:
R>1. Есть несколько складов. На складе располагаются товары.
R>2. Есть операции приемки товара на склад, перемещения на другой склад и списания со склада.
R>3. Необходима возможность просмотреть прошлое состояние склада (ограничение, например, за год)
R>4. Необходимо хранить данные по прошедшим операциям.
R>5. Необходима возможность отмены и изменения прошедшей операции приемки/перемещения/списания.
R>6. Прошедшие операции следует хранить не более 1 года.

1. Взять готовое решение (например, 1С); слегка доработать напильником, если надо.
2. Сделать хранилище данных (ХД), в которое ежедневно (чаще или реже, зависит от ваших необходимостей) загружать сделанные изменения. ХД как раз и будет источником исторических изменений.
3. Из ХД делать аналитику с помощью какого-нибудь OLAP'а и/или репортингового тулза.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Poudy, Вы писали:

P>>Бухгалтерия тут не при чем, я говорил о складских проводках.
G>А склад остатки уже не является объектом бухгалтерского учета?

да при тут этот вопрос? не видел WMS без бухгалтерии?

P>>Ведь строки документов склада тоже не надо мешать в кучу с остатками, а иметь отдельные складские проводки для склада, правда же?
G>Чето не понял что от чего предполагается отделять и зачем.

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