php - 我应该使用 EAV 模型吗？

Question

我正在为电子商务应用程序设计数据库/域，但我很难弄清楚如何存储产品。

该网站将销售各种产品，钢笔、丁字裤、纹身、雨伞，应有尽有。这些产品中的每一个都会共享一些共同的属性，高度、宽度、长度、重量等，但有些产品有特殊的数据。例如，钢笔有不同的墨水颜色， Nib /笔盖和小册子可以有不同类型的折叠。到目前为止，我已经想出了一些 20 多个额外属性，但这些属性可能只适用于网站上 1% 的产品。

所以我想知道是否适合实现 EAV 模型来处理额外的数据。请记住，当客户在前端查看该网站时，将会有一个过滤侧边栏，就像 eBay 和 carsales.com.au 上一样。 (因此请记住，会有相当多的查询)

我认为实现类表继承并不实际，因为系统需要保持灵 active 。这是因为， future 我们可能会通过新型产品拥有更多属性。

我考虑过的另一件事是使用 NoSQL 数据库(可能是 MongoDB)，但是我对这些类型的数据库缺乏经验，它能解决我的问题吗？

选项回顾:

1. 具有大量列的单一产品实体
2. 单独的属性实体 (EAV)
3. 切换到无模式持久化

我正在构建带有属性实体的原型(prototype)，以了解它的灵 active ，并测试性能以及查询的失控程度。

编辑:我当然愿意接受任何其他解决方案。

Answer 1

很好的问题，但是当然，没有“唯一正确的方法”。根据@BenV，Magento 确实使用 EAV 模型。我对它的体验非常积极，但它确实让其他用户感到困惑。一些注意事项:

<强>1。性能。EAV 需要复杂的多表连接来使用相关属性填充对象。这确实会导致性能下降。但是，可以通过仔细的缓存(在堆栈的所有级别，包括查询缓存)和选择性使用非规范化来缓解这种情况。 Magento 确实允许管理员为 SKU 数量(通常为数千)的类别和产品选择非规范化模型。这反过来又需要观察者在产品数据发生变化时触发重新索引(总是好的!)并更新“平面”非规范化表。也可以通过向管理员提示来安排或手动触发。

<强>2。第三方用户复杂性如果您打算向其他用户提供此应用程序，许多人会发现 EAV 太复杂，并且您最终会在用户论坛上处理大量的提示和不知情的滥用行为(引用 Magento!!)。

<强>3。 future 的可扩展性和插件架构。毫无疑问，当可扩展性成为一个因素时，EAV 模型才真正发挥作用。在模型中添加新属性非常简单，同时最大限度地降低破坏现有 ORM 和 Controller 代码的风险。

<强>4。数据类型的变化EAV 确实使更改属性数据类型变得更加困难。如果您的初始设计需要将来更改的特定属性数据类型(例如将 int 更改为 varchar)，则意味着您必须将该属性的所有记录迁移到与新数据类型匹配的相应表。当然，纯粹主义者会建议您第一次就把设计做好，但现实有时确实会干扰您!

<强>5。手动产品导入EAV 几乎不可能完成的一件事是使用 SQL 和/或 phpMyAdmin 样式的 CSV/XML 将产品(或其他实体)导入数据库。您需要编写一个导入器模块来接受结构化数据并将其传递到应用程序的模型层以将其保存到数据库中。这确实增加了你的复杂性。