1

几天来，我一直在尝试为我的问题提出解决方案，但没有运气。我希望有人能帮助我。如果描述太长，我很抱歉。

我想建立一个网站，客户可以在其中选择这些产品并可以订购它们的任意组合。

产品一：

完全定制的产品（即使不是所有信息对表结构都很重要，我也会详细描述定制过程）

客户可以从组件列表中组装产品，并且：

  1. 有两种类型的组件 - 主要组件和辅助组件
  2. 每个组件都有特定的重量和价格
  3. 主要组件由辅助组件组成，但它们的权重与单独列出时不同（对于跟踪哪个组件的销售量很重要）
  4. 每个产品必须恰好包含 1 个主要成分，并且可以包含 0 到多个补充成分
  5. 辅助成分的总重量总是 <= 主要成分的重量
  6. 主成分最终重量按“原主成分重量-辅成分总重量”计算

例如。

添加主要成分MC（重量1000g）
添加Sup。组分 1 (重量 100g)
添加 Sup. 组分2（重量200g）

最终产品包括：
主要成分 MC 700g
Sup。组分 1 100g
Sup. 组分 2 200g

每个产品都有唯一的代码（原因稍后解释）。

产品乙：

预组装并直接购买的产品（由组件制成，但组件的重量可能与在组装模块中单独列出时的重量不同）

产品C：

其他与组件无关的物品 - T 恤、马克杯

我的问题是 - 在以下情况下，存储这些项目的订单最有效的数据库结构是什么：

  1. 我需要显示特定订单的所有订单项目，当存在产品 A 时，列出它的所有组件和主要组件的组件
  2. 我需要能够通过代码重建已经购买的定制产品（产品 A），并在它们不再有库存/可用时移除单个组件
  3. 所有组件的重量和价格可以随时间变化+主要组件的组件和产品B也可以改变
  4. 我需要能够跟踪每个组件的销售量以及销售时间

到目前为止，我有以下数据库结构，但我认为我没有走在正确的轨道上：

成分

  • 身份证（PK）
  • 姓名
  • 价格
  • 重量

订单（不相关的列，如 number、customer_firstname、delivery_method 等省略）

  • 身份证（PK）

order_items（所有产品类型共有的字段）

  • 身份证（PK）
  • order_id（FK 到 orders.id）
  • 代码
  • 姓名
  • 价格
  • 数量

order_producta

  • 身份证（PK）
  • order_item_id（FK 到 order_items.id）
  • component_id（FK 到 components.id）
  • 数量
  • 价格
  • 重量

非常感谢您的回复。如果我解释不清楚，我很乐意用其他信息编辑我的问题。

4

0 回答 0