1

私は数日間、自分の問題の解決策を考え出そうとしていますが、運がありません. 誰かが私を助けてくれることを願っていました。説明が長すぎてすみません。

顧客がこれらの製品から選択し、それらを自由に組み合わせて注文できる Web サイトを構築したいと考えています。

製品 A:

完全にカスタマイズされた製品 (すべての情報がテーブル構造にとって重要ではない場合でも、カスタマイズ プロセスについて詳細に説明します)

お客様は、コンポーネントのリストから製品を組み立てることができます。

  1. 成分には主成分と補助成分の2種類があります
  2. 各コンポーネントには特定の重量と価格があります
  3. メインコンポーネントは補助コンポーネントで構成されていますが、単独でリストされている場合とは重量が異なります (どのコンポーネントがどれだけ販売されたかを追跡するために重要です)。
  4. 各製品には必ず 1 つの主成分が含まれている必要があり、0 個以上の補助成分を含むことができます
  5. 補助コンポーネントの総重量は常に <= 主コンポーネントの重量です
  6. 主成分の最終重量は、「元の主成分の重量 - 補助成分の合計重量」として計算されます。

例えば。

add 主成分 MC (重量 1000g)
add Sup. 成分１（重さ１００ｇ）
にＳｕｐ．コンポーネント 2 (重量 200g)

最終製品の構成:
主成分 MC 700g
Sup. 成分 1 100g
Sup. コンポーネント2 200g

各製品には固有のコードがあります (理由は後で説明します)。

製品 B:

事前に組み立てられ、直接購入できるように製造された製品 (部品で作られていますが、部品は組み立てモジュールに単独で記載されている場合とは重量が異なる場合があります)

製品 C:

コンポーネントに関係のないその他のアイテム - Tシャツ、マグカップ

私の質問は、次の場合に、これらのアイテムの注文を保存するための最も効率的なデータベース構造は何でしょうか?

  1. 特定の注文のすべての注文項目を表示する必要があり、製品 A が存在する場合は、そのすべてのコンポーネントとメイン コンポーネントのコンポーネントをリストします
  2. すでに購入したカスタマイズされた製品 (製品 A) をコードで再構築し、在庫がなくなった場合や入手できない場合は個々のコンポーネントを削除できるようにする必要があります
  3. すべてのコンポーネントの重量と価格は時間とともに変化する可能性があります + 主なコンポーネントのコンポーネントと製品 B も変化する可能性があります
  4. 各コンポーネントの販売量と販売時期を追跡できる必要がある

これまでのところ、次のDB構造がありますが、正しい軌道に乗っているとは思いません:

コンポーネント

  • ID (PK)
  • 名前
  • 価格
  • 重さ

注文(number、customer_firstname、delivery_method などの関連しない列は省略)

  • ID (PK)

order_items (すべての商品タイプに共通のフィールド)

  • ID (PK)
  • order_id (orders.id の外部キー)
  • コード
  • 名前
  • 価格
  • 量

order_producta

  • ID (PK)
  • order_item_id (order_items.id の外部キー)
  • component_id (components.id への外部キー)
  • 量
  • 価格
  • 重さ

お返事ありがとうございます。不明な点を説明した場合は、追加情報で質問を喜んで編集します。

4

0 に答える 0