我应该使用EAV模型吗？

Question

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

该网站将出售各种各样的产品，笔，丁字裤，纹身，雨伞等等。这些产品中的每一个将共享一些共同的属性，例如高度，宽度，长度，重量等，但是某些产品具有特殊的数据。例如，钢笔具有不同的墨水颜色，笔尖/笔盖和小册子可以具有不同类型的折痕。到目前为止，我已经考虑了20多个额外的属性，但是这些属性可能仅适用于网站上1％的产品。

因此，我想知道是否适合实施EAV模型来处理额外的数据。请记住，当客户在前端查看站点时，将在eBay和carsales.com.au上有一个过滤侧边栏。（因此请记住，会有很多查询）

我认为实现类表继承是不切实际的，因为系统需要保持灵活性。这是因为，随着时间的流逝，将来我们可能会使用新型产品来拥有更多属性。

我考虑过的另一件事是使用NoSQL数据库（可能是MongoDB），但是我对这些类型的数据库经验不足，是否可以解决我的问题？

审查选项：

1. 具有许多列的单一产品实体
2. 分隔属性实体（EAV）
3. 切换到无模式持久性

我正在构建带有属性实体的原型，以了解其灵活性，并测试性能以及查询如何失控。

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

Answer 1

很好的问题，但是当然，没有“一个真正的方法”。根据@
BenV，Magento确实使用了EAV模型。我对它的使用感到非常积极，但是它确实使其他用户感到震惊。一些注意事项：

1.性能。
EAV需要复杂的多表联接，才能使用相关属性填充对象。确实会导致性能下降。但是，可以通过谨慎地缓存（在整个堆栈的各个级别，包括查询缓存）以及选择性地使用非规范化来缓解这种情况。Magento确实允许管理员为SKU数量允许的类别和产品选择非规范化模型（通常为数千个）。反过来，这需要观察者触发重新索引（总是很好！），并在产品数据更改时更新到“平面”非规范化表。这也可以计划或手动提示管理员。

2.第三方用户的复杂性
如果您打算将该应用程序提供给其他用户，许多人会发现EAV太复杂了，您最终将在用户论坛上遇到很多令人沮丧和无知的滥用（请参阅Magento！）。 。

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

4.数据类型的更改
EAV确实很难更改属性数据类型。如果您最初的设计要求特定属性的数据类型，在未来的变化（说int来varchar），这意味着你必须迁移的所有记录的该属性相匹配的新的数据类型对应表。当然，纯粹主义者会建议您在第一时间就获得正确的设计，但现实确实会干扰您！

5.手动产品导入 EAV几乎不可能做到的一件事是使用SQL和/或phpMyAdmin样式的CSV /
XML将产品（或其他实体）导入数据库。您需要编写一个Importer模块，该模块接受结构化数据并将其通过应用程序的Model层传递，以将其持久化到数据库中。这确实增加了您的复杂性。