产品定制选项的数据库模型

Question

我正在设计一个电子商务，其中各个项目的每个产品都有不同的自定义选项，并且正在考虑构建数据库的最佳方法。例如，我可能想要出售红色或白色以及不同尺寸的东西，但另一件可能只能以绿色或红色出售而没有尺寸选项。我有一些我在下面概述的天真的方法，但想知道是否有任何想法。除非有充分理由转向NoSQL，否则我想保持这种关系。

1. 选项1：为每种类型的选项提供单独的表格。例如，一个表包含所有可能颜色的列表，另一个表使用颜色子集引用此表，并且还与产品相关联。然后会有另一个表来处理为添加到购物车中的实际产品选择的颜色。
2. 选项2：由于每个产品的选项数量最少，为什么不只是拥有一组包含每个可能选项的值的列。这基本上是具有名为“颜色”的文本列的产品表，然后只列出可用的颜色选项。我个人不喜欢这个，因为它太有限了 - 如果我想将图像与每种颜色相关联或根据选项改变定价怎么办？
3. 选项3：前两个产品的组合，其中每个产品都有一组列，这些列将引用可用的自定义选项。例如，每个产品都有一个“颜色选项”列，如果不为空，则可用于该产品，并指向一组结构良好的选项。

Answer 1

选项4：

有一个处理多个选项的选项表。

Option
------
Option ID
Item ID
Category ID
Category Text

选项ID是一个自动递增的序号。

项目ID是指向项目的整数。

类别ID是表示类别的整数。例如，Color为1，Size为2。

类别文字是实际的颜色或大小。

此方法有意义当且仅当您不想搜索所有已售出的红色商品或所有已销售的XL商品。

此类数据设计称为entity / attribute data model。

Answer 2

我会使用类似以下架构的东西：

表'产品'

Product id
Product name
Product base price

表'尺寸'

Size ID
Size name
Additional price

表'颜色'

Colour ID
Colour Name
Additional price

表'SaleItems'

SaleItem ID
Product ID
Size ID
Colour ID

客户会购买'SaleItems'表格中包含的商品。项目的一个例子是马球T恤，它有四种不同的尺寸和三种不同的颜色。这样，你在'SaleItems'表中就会有12行，每一行都有不同的特征，但能够知道出售了多少件马球衫，有多少件红色衬衫（所有类型的产品都已售出），有多少件XL物品等等。

您可能不需要价格字段，但想法是基本马球T恤需要10个单位;小尺寸没有附加价格，而XL有10％的额外价格。大多数颜色可能会花费相同，但一些异国情调的颜色可能会花费10％以上。这种异国情调的XL polo T恤将花费10 * 1.1 * 1.1 = 12.1单位。

此架构假设所有产品都具有所有尺寸和颜色。