Управление запасами узлов и их частей (взаимосвязей)

Question

Я должен отслеживать запас отдельных деталей и комплектов (сборок) и не могу найти удовлетворительный способ сделать это. Образец фиктивной и гипер упрощенной базы данных:

Table prod:
prodID  1
prodName Flux capacitor
prodCost 900
prodPrice 1350 (900*1.5)
prodStock 3
-
prodID  2
prodName Mr Fusion
prodCost 300
prodPrice 600 (300*2)
prodStock 2
-
prodID  3
prodName Time travel kit
prodCost 1200 (900+300)
prodPrice 1560 (1200*1.3)
prodStock 2

Table rels
relID  1
relSrc  1 (Flux capacitor)
relType  4 (is a subpart of)
relDst  3 (Time travel kit)
-
relID  2
relSrc  2 (Mr Fusion)
relType  4 (is a subpart of)
relDst  3 (Time travel kit)

prodPrice: рассчитывается на основе стоимости, но не линейным образом. В этом примере для затрат 500 или меньше наценка составляет 200%. Для расходов 500-1000 наценка составляет 150%. Для расходов от 1000+ наценка составляет 130% Вот почему комплект для путешествий во времени намного дешевле, чем отдельные детали

prodStock: вот моя проблема. Я могу продавать комплекты или отдельные детали, поэтому запас комплектов является виртуальным.

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

Проблема, когда я продаю: Если бы я только продавал наборы, рассчитать запас было бы легко: «У меня есть 3 конденсатора Flux и 2 Mr Fusions, поэтому у меня есть 2 комплекта Travel Time и конденсатор Flux» Но я могу продать комплекты или отдельные детали. Итак, я должен отслеживать запас отдельных деталей и возможные комплекты одновременно (и я должен компенсировать цену продажи)

Возможно, это действительно просто, но я не вижу простого решения. Возобновление: я должен найти способ отслеживания запаса, и база данных / программа - это тот, кто должен это сделать (я не могу попросить клерка исправить запас)

Я использую php + MySql. Но это более логичная проблема, чем программная

Обновление: к сожалению, решение Eagle не сработает.

• отношения могут быть и являются рекурсивными (один набор использует другой набор)
• Существуют комплекты, в которых используется более одной и той же детали (2 конденсатора + 1 Mr Fusion)
• Мне действительно нужно сохранить значение запаса комплекта. Эта же база данных используется для веб-страницы, где пользователи хотят купить запчасти. И я должен показать доступные запасы (иначе они даже не будут пытаться купить). И не могу себе позволить подсчитать запас при каждом поиске пользователя на веб-странице

Но мне понравилась идея логического обозначения акции как виртуальной

Answer 1

Хорошо, прежде всего, поскольку prodStock для набора для путешествий во времени виртуален, вы не можете сохранить его в базе данных, это будет по сути вычисляемое поле. Вероятно, было бы полезно, если бы в таблице было логическое значение, которое говорит, рассчитывается prodStock или нет. Я сделаю вид, что у вас есть это поле в таблице, и пока я назову его isKit (где TRUE означает, что это комплект, а prodStock должно быть рассчитано).

Теперь для расчета количества каждого товара на складе:

select p.prodID, p.prodName, p.prodCost, p.prodPrice, p.prodStock from prod p where not isKit
union all
select p.prodID, p.prodName, p.prodCost, p.prodPrice, min(c.prodStock) as prodStock
from 
  prod p
  inner join rels r on (p.prodID = r.relDst and r.relType = 4)
  inner join prod c on (r.relSrc = c.prodID and not c.isKit)
where p.isKit
group by p.prodID, p.prodName, p.prodCost, p.prodPrice

Я использовал псевдоним c для второго продукта, чтобы обозначить «компонент». Я явно написал not c.isKit, поскольку это не будет работать рекурсивно. union all используется вместо union по соображениям эффективности, поскольку они оба будут возвращать одинаковые результаты.

Предостережения:

• Это не будет работать рекурсивно (например, если комплект требует компонентов от другой комплект).
• Это работает только на наборах которые требуют только одного из конкретных предмет (например, если потребовать 2 конденсатора потока и 1 Мистер Фьюжн, это не сработает).
• Я не проверял это, поэтому могут быть незначительные синтаксические ошибки.
• Это только вычисляет поле prodStock; для заполнения других полей вам потребуется аналогичная логика.

Если ваш запрос намного сложнее, чем я предполагал, я прошу прощения, но я надеюсь, что это поможет вам найти решение, которое будет работать.

Что касается обработки данных при покупке комплекта, предполагается, что вы должны хранить prodStock только в составных частях. Так, например, если вы покупаете машину времени у поставщика, вместо увеличения prodStock на продукт машины времени, вы бы увеличили его на конденсаторе потока и Mr. fusion.