1

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

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

2 回答 2

0

选项 4：

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

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

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

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

类别 ID 是表示类别的整数。例如，颜色为 1，尺寸为 2。

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

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

这种类型的数据设计称为实体/属性数据模型。

于 2012-10-03T17:55:21.527 回答
0

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

表“产品”

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 行，每行具有不同的特征，但能够知道销售了多少 Polo 衫、多少红色衬衫（销售了所有类型的产品）、多少 XL 商品， ETC。

您可能不需要价格字段，但基本款马球 T 恤的价格为 10 件；小号没有附加价格，而 XL 有 10% 的附加价格。大多数颜色的价格可能相同，但一些异国情调的颜色可能会贵 10%。一件这种异国情调的 XL polo T 恤将花费 10 * 1.1 * 1.1 = 12.1 个单位。

此模式假定所有产品都可以具有所有尺寸和颜色。

于 2012-10-04T09:01:55.307 回答