Структура БД. Нужны советы.

[akxxiv]

Структура БД. Нужны советы.

Доброе время суток всем. Нужны Ваши советы.

Задача.

Товар перевозится из пункта А в пункт С через пункт В (склад логистической компании (ЛК) ). Нужно отслеживать его целостность. Бизнес-процесс такой.

1. Клиент привозит на склад ЛК по накладной товар. Кладовщик принимает товар на склад и сравнивает фактическое его количество и количество по накладной. В случае расхождений составляется АКТ № 1 («недовоз Клиентом на склад»). Пример:

1. П1 - 1кг
2. П2 - 1кг
   [/list=1]
   2. Экспедитор принимает товар на складе по той же накладной и выявляется недостача и оформляется Аскт № 1В («Внутренний акт - потери на складе»):
   1. П1 - 1кг (это тянется из первого акта)
   2. П2 - 2кг (а здесь 1кг из первого акта, а 1 гк потерялись где-то на складе)
      [/list=1]
      3. Экспедитор везет товар в Магазин, в котором товар принимают по той же накладной и составляется Акт №2 («неприемка груза грузополучателем»)
      1. П1 - 1кг (из предыдущего акта)
      2. П2 - 2кг (из предыдущего акта)
      3. П3 - 1кг (поврежден в дороге)
         [/list=1]
         Поврежденный товар отправляют обратно.
         
         
         Таким образом получаем до 3х документов по одной накладной, которые отражают разный жизненный цикл одних и тех же товаров.
         
         
         Я себе пока это вижу в нескольких вариантах.
         
         1. Вариант.
         
         Таблица актов «acts» - id | wb_id | type | positions_arr | properties{1...n}
         Таблица позиций «positions» - id | title | unit | price | value_1 | value_2 | value_3
         
         Т.е. акт в зависимости от типа имеет свои свойства, а в поле positions_arr сериализованный массив id-шников позиций акта. В зависимости от типа акта вытаскивается то или иное значение позиции.
         
         2. Вариант.
         
         Таблица актов «acts» - id | wb_id | type | properties{1...n}
         Тут акты имеют объединяющий элемент - wb_id - id накладной на основе которой он выставлен. при чем имеет составной уникальный индекс wb_id + type, т.е. по данной накладной может быть выставлен только один акт одного каждого типа.
         
         Таблица позиций «positions» - id | wb_id | title | unit | price
         Здесь если акт выставляется по накладной, то и позиции привязываются к накладной. Каждая озиция имеет свой id.
         
         Таблица значений позиций «position_values» - position_id | act_id | value
         
         
         3. Вариант.
         
         Тблца актов «acts» - id | wb_id | properties{1..n}_for_type{1..3}
         Т.е. сводная таблица актов. Каждая запись содержит в себе все 3 акта.
         
         Таблица позиций «positions» - id | act_id | title | unit | price | value_1 | value_2 | value_3
         
         Вот. Пока что в голову пришло. Что-то мудранул я тут. Пока в голове как в тумане

 

[whirlwind]

А в чем вопрос-то?

 

[akxxiv]

Ну, не то чтобы вопрос. Совет нужен. Может кто оценит предложную мной структуру, выявит недостатки и достоинства, может свою предложит.

У меня щас в голове каша. Просто надеюсь что с помощью ваших советов смогу ее как-то переварить. Так сказать по полочкам все разложить. Если конечно Вам не сложно...

 

[whirlwind]

Что бы каши не было, люди придумали классику. Начните с выявления сущностей. Потом на их основе сделаете таблицы. Товар, контрагент, документ, итп. И не надо ничего особо выдумывать.

 

[prolis]

с кашей лучше разобраться как посоветовали.
все три варианта поэтому не подходят совсем
на практике партия товара из А в Б может пойти частями, а из B пойти одна часть в C, а другая в D, что бы потом всё-таки в C
что бы не хардкодить потом, нужно сразу сущности правильно выделять.
Да и в складском учете, и в логистическом есть свои ньюансы товарно-материального учета.