什么是产品，选项和类别最优雅的MySQL架构？

Question

我使用过十几个模板系统（Zen Cart，Cube Cart等）。每种方法都有自己奇怪的方式来构建产品，选项和类别。所有附加功能都会导致McGuyver堆叠的卡片情况，这使得使用代码成为一种全面的阻力。

所以六年前我建立了自己的网络商店引擎，这种引擎多年来不断发展，并成为自己的一堆卡片。现在我正在对发动机进行全面检修。虽然没有一个引擎能够满足所有网络商店的需求，但我想知道以下模型是否有任何缺点，或者是否有更好的方法来创建灵活，规范化，非讨厌的商业数据库：

注意：
option_types =颜色，尺寸，材料
options =红色，白色，蓝色，S，M，L，棉，氨纶，皮革

除了故意遗漏的基本内容（位置，主动等）之外，有人看到了改善这种情况的方法吗？

Answer 1

以下是我对此的说明/意见。你错过了基数，但我会尽力猜测它们。

• Categories没问题。

• 从id移除item_categories，因为您没有使用它。在category_id和item_id上创建复合主键。

  

给每个记录一个唯一的ID在很多方面更聪明：在一个字段上查找比在两个字段上查找更快，更容易删除等等

你会对该ID进行什么查询？您将运行的查询是：“获取项目的所有类别”和“获取类别的所有项目”。我不明白为什么删除会更安全。但是，我会说添加id可能不会更新，因为您可能有不同的ID，但class_id和item_id对相同。你必须检查那里的约束并确保这些对是唯一的（而不是那些用于PK的那些？）

• items没问题（见下面的评论）
• 从id移除item_options（与上述情况相同，请参阅下面的评论）
• option_types没问题

现在，我认为项目和选项的相关方式需要更多思考。这似乎是一种多对多的关系。作为一件物品，如T恤衫可以有很多尺码，说每件物品和选项应该有不同的尺寸是有道理的。但是，除了尺寸之外，你还会有不同的材料，比如棉和皮革。您将需要有关于棉-S，棉-M，棉-L和皮革-S，皮革-M和皮革-L对的信息。这是有道理的，因为我很确定所有这些都会有不同的价格和重量。但是现在让我们为T恤添加两种颜色。您必须为我们现在拥有的12种组合中的每种组合添加价格和重量。

更不用说如果用户想要查看商品的价格，他必须选择所有选项，直到达到价格为止。我不知道应该怎么做，因为我不知道要求。我只想提出一个想法：你可以在基本价格和重量上应用价格和重量变化，这将是该项目的一部分。

睡觉前只是一些未经处理的想法：

• option_types可能是某种层次结构
• 在给定设计的情况下，仔细考虑如何处理stock。你将有10件黑色T恤项目......但是你有多少件黑色皮革T恤衫？这个数字与10个原始数字有什么关系？

Answer 2

选项表我会在名称下添加值。即 黑色L 黑色M. 黑S 蓝L 蓝色M. 蓝S 等等 作为对莫斯蒂的想法的一种分离。