我应该使用EAV模型吗？

php doctrine-orm magento entity-attribute-value database-design

2022-08-30 14:48:18

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

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

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

我不认为实现类表继承是可行的，因为系统需要保持灵活性。这是因为，在未来，我们可能会有更多的属性与新型产品。

我考虑过的另一件事是使用NoSQL数据库（可能是MongoDB），但是我对这些类型的数据库几乎没有经验，它甚至能解决我的问题吗？

审查选项：

具有大量列的单个产品实体
独立属性实体（EAV）
切换到无架构持久性

我正在构建一个具有属性实体的原型，以查看它的灵活性，并测试性能以及查询的失控程度。

编辑：当然，我对任何其他解决方案持开放态度。

答案 1

很好的问题，但当然，没有“一条真正的道路”。根据@BenV，Magento确实使用EAV模型。我对它的体验非常积极，但是它确实绊倒了其他用户。一些注意事项：

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

2.第三方用户复杂性 如果您打算将此应用程序提供给其他用户，许多人会发现EAV太复杂，您最终会在用户论坛上处理大量虚张声势和无知的滥用行为（ref Magento！！）。

3. 未来的可扩展性和插件架构。毫无疑问，当可扩展性是一个因素时，EAV模型确实会成为它自己的。向模型中添加新属性非常简单，同时最大限度地降低破坏现有ORM和控制器代码的风险。

4. 数据类型 EAV 的更改确实使更改属性数据类型变得更加困难。如果初始设计要求将来更改的特定属性数据类型（例如更改为），则意味着您必须将该属性的所有记录迁移到与新数据类型匹配的相应表中。当然，纯粹主义者会建议你第一次就把设计做对，但现实有时会侵入！intvarchar

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

答案 2

开源购物车Magento允许使用EAV设计为其产品自定义属性。您可以在此处查看他们的数据库架构。