电子商务项目的数据库设计（我应该使用 EAV 方法）

Posted 2023-02-23

【中文标题】电子商务项目的数据库设计（我应该使用 EAV 方法）

【英文标题】：Database Design for ECommerce project (Should I use EAV Approach)

【发布时间】：2012-04-04 12:21:39

【问题描述】：

我即将设计我的第一个电子商务数据库。

我在大多数电子商务网站中发现的是，这些网站有类别，然后是子类别，然后是子类别，依此类推。并且SubCategory的深度不固定意味着一个Category有六个嵌套的SubCategory，而另一些则不同

现在所有产品都有与之关联的属性。

现在我的问题是这些网站是否继续为嵌套子类别添加表格并继续为数据库中的属性添加列

或

他们应用称为“EAV”模型的东西（如果我是对的）来解决这个问题，或者他们继续添加列和/或表格并继续更新网页，因为在我发现的许多网站上现在有一个新的类别。

（如果他们使用 EAV 模型，那么网站性能会受到影响不是吗..）

由于这是我的第一个电子商务项目，请提供您的一些宝贵建议。

谢谢，

感谢任何帮助。

【问题讨论】：

阅读 this excellent article ("Bad CaRMa") 并了解 on this list of the 5 top mistakes in database design (point #3) 为什么 EAV 是一个非常糟糕的主意.....

【参考方案1】：

您需要的是产品功能的EAV和产品类别的嵌套集的组合。

虽然我当然同意 EAV 几乎总是一个糟糕的选择，但 EAV 是完美选择的一个应用程序是用于处理在线目录中的产品属性。

想想网站如何显示产品属性...产品的属性总是显示为一个垂直列表，有两列：“属性”| “价值”。有时，这些列表显示多个产品的并排比较。 EAV 非常适合做这种事情。使 EAV 对大多数应用程序而言毫无意义且效率低下的因素正是使 EAV 对在线目录中的产品属性有意义且高效的原因。

每个人总是说“EAV 是邪恶的！”的原因之一是 EAV 中的属性是“无意义的”，因为列名（即属性的含义）是表驱动的，因此不是由模式定义的。模式的全部意义在于赋予您的模型意义，因此这一点很好。 然而在在线产品目录的情况下，产品属性的含义对于系统本身来说并不重要。您的目录系统关心产品属性的唯一原因是将它们转储到列表或可能的产品比较矩阵中。因此，EAV 并不碰巧是邪恶的在这种特殊情况下。

对于产品类别，您需要一个嵌套集模型，正如我在this question 的回答中所描述的那样。嵌套集使您能够非常快速地检索以及遍历不平衡层次结构的多个级别，但需要在编辑时进行一些预先计算。