根据变体和价格进行产品的数据库架构设计
Was*_*abi 0 mysql database-design relational-database entity-attribute-value
我们正在为电子商务应用程序和网站设计数据库。我们遇到了一个障碍，使我们在搜索和实验中陷入困境，但没有一个解决方案有效，因为数据中存在冗余。
我们做了一些被拒绝的设计。我不会展示所有的设计，但我会在这里展示其中的一些设计以及我们即将实现的最后设计之一。
- 这是我们拒绝的第一个设计，因为它过于标准化并且过于复杂。
- 第二个设计是同样的事情。
- 这是我们最后尝试的设计，但过于简化，冗余会很多。
之后，我们尝试搜索并寻找一种能够工作并适合我们之前的设计到其他桌子的设计。我们在这里发现了一个，我们对设计做了一些修改，但它也不适合我们，因为 color_id 和 size_id 会发生冗余，而且它不是外键。
我们想要设计接受这些情况的表：
我有一种具有不同颜色和不同尺寸的产品，而且尺寸不取决于颜色，反之亦然，而且它们的价格都相同。
我有一个产品，它有不同的颜色和尺寸，但尺寸取决于颜色，例如（颜色：红色）有（尺寸：S、M、L），（颜色：黑色）有（尺寸：M、L）和他们有不同的价格。
我有一个产品，它有不同的尺寸，价格变化取决于尺寸，例如产品表（尺寸：S）和（价格：50 美元），但（尺寸：L）有（价格：100 美元）。但它没有颜色变体。
这些产品不会由我们插入，而是由一些卖家插入。颜色和尺寸将是下拉菜单中的所有选择。并且尺寸将仅根据类别显示。例如，类别上衣只有 (S、M、L...)，没有其他尺寸
从实体和关系开始。完成后，每个实体都会获得自己的表格。认真理解现实世界的实体及其在数据世界中的表示。
- 你
product绝对是一个实体。 - 产品
variant也是一个实体。 - A
product有一个或多个variants。这是一对多的关系。（如果产品没有尺寸或颜色，则为variant通用产品。 - 每个
variant都有库存属性，例如 sku_number 和 number_in_stock。
您不能使用product来保持库存。考虑一下：您的产品是一件 T 恤。但你并没有用完T 恤，而是用完了小红色 T 恤，你必须从供应商那里订购更多。
到目前为止两个实体：
product:1 到 N:variant。
让我们考虑具有产品属性集合的变体。让我们创建attribute一个实体。每个属性都有一个类型：例如“size”、“color”、“accent_color”。所以你的attribute表包含这些列。
attribute_id PK
attribute_type VARCHAR(63) 'size', 'color', ...
attribute_value VARCHAR(63) '30', 'red', ...
您有一个多对多连接表variant_attribute。该表中存在一行意味着该变体具有该属性。
variant_id PK
attribute_id PK
所以，我们最多有三个实体。
product:1 到 N:variant:0-N 到 0-N:attribute。
这是用四个表完成的product，，，，，variantvariant_attributeattribute
（如果你想完全分开处理颜色和尺寸，你也可以这样做。但是我提出的方案是可扩展的：如果有人告诉你下一步要销售某种东西的“冷”、“暖”和“热”变体今年您将不必重新发明轮子。）
这些是重要的实体和关系：它们描述了客户订购的商品以及仓库中必须出售的商品。它们需要足够简单，以便在午夜在生产中排除故障，并且足够具有表现力来代表您的现实世界实体。正确处理架构的该部分。
然后添加类别和部分。我无法从你的最后一张图中看出你想要什么。您可能应该重新访问应用程序的该部分的实体。
如果你想出售所有红色的东西，你可以这样做：
attribute_id PK
attribute_type VARCHAR(63) 'size', 'color', ...
attribute_value VARCHAR(63) '30', 'red', ...