产品、选项和类别最优雅的 MySQL 模式是什么？答案

【问题标题】：What's the most elegant MySQL schema for products, options and categories?产品、选项和类别最优雅的 MySQL 模式是什么？
【发布时间】：2012-03-05 05:12:41
【问题描述】：

我使用过十几个模板系统（Zen Cart、Cube Cart 等）。它们中的每一个都有自己奇怪的产品、选项和类别的结构方式。所有的附加功能都导致了 McGuyver 的一堆纸牌情况，这使得使用代码成为一种完全的拖累。

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

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

除了故意省略的基本内容（位置、活动等）之外，还有人认为有办法改进吗？

【问题讨论】：

你是用什么软件制作的？
为什么item_categories 和item_options 有id 属性而不是(category_id, item_id) 和(item_id, option_id) 主键？
@camus ondras.zarovi.cz/sql/demo
@FrancisAvila 好问题......最初我在items 中有category_id，但发现我的足够多的客户（~20%）希望每个项目有多个类别。所以上面的模式最终成为最干净的方法。
我发现相反的情况：它不是规范化的表单、重复的条目、更大的表、两个索引而不是一个。我怀疑速度是否有任何显着差异，但如果有你的方式会更慢。阅读 SQL 反模式 的“需要 ID”一章，更详细地了解为什么这不优雅。

标签： php mysql e-commerce

【解决方案1】：

这是我对此的注释/意见。您缺少基数，但我会尽力猜测它们。

Categories 没问题。
从item_categories 中删除id，因为您不使用它。在 category_id 和 item_id 上创建复合主键。

给每条记录一个唯一的 id 在很多方面更聪明：在一个字段上查找比在两个字段上查找更快、删除更安全等

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

items 没问题...（见下面的 cmets）
从item_options 中删除id（与上面的情况相同，请参见下面的 cmets）
option_types 还可以

现在，我认为项目和选项的关联方式需要更多思考。这似乎是一个多对多的关系。作为一件物品，例如一件 T 恤可以有多种尺寸，因此说每对物品和选项应该有不同的尺寸是有道理的。但是，除了尺寸之外，您还有不同的材料，例如棉和皮革，会发生什么情况。您必须了解棉-S、棉-M、棉-L 和皮革-S、皮革-M 和皮革-L 的配对信息。这是有道理的，因为我很确定它们都会有不同的价格和重量。但是现在让我们为我们的 T 恤添加 2 种颜色。您必须为我们现在拥有的 12 种组合中的每一种添加价格和重量。

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

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

option_types 可能是某种层次结构
仔细考虑考虑到该设计您将如何处理stock。一件黑色 T 恤有 10 件物品……但一件黑色皮革 T 恤有多少件物品？这个数字与原来的 10 个有什么关系？

【讨论】：

我已经更新了图形以显示更多关于选项的想法...option_sets 将包含每个选项的一条记录，例如“Cotton, S, Black”将是 3 条记录。

【解决方案2】：

选项表我会在名称下添加值。 IE。黑色 L 黑色 M 黑S 蓝色 L 蓝色 M 蓝色 S 等等作为莫斯蒂想法的衍生产品。

【讨论】：