我应该使用 EAV 模型吗？答案

【问题标题】：Should I use EAV model?我应该使用 EAV 模型吗？
【发布时间】：2011-05-03 06:16:09
【问题描述】：

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

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

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

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

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

选项审查：

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

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

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

【问题讨论】：

您手动构建电子商务应用程序是否有特殊原因？这可能很困难、很危险，而且可能有点不必要……
刚找到的this question 好像和你问的差不多。
@BenV，虽然问题很相似，但答案可能完全不同，尤其是与 Magento 相关的问题。 Magento 最初确实在 EAV 性能方面遇到了困难，但他们通过仔细缓存（查询、模型、html 块和整页）和可选的非规范化解决了这个问题。自从提出这个问题以来，这些都是新的发展，值得在这种情况下重新提出这个问题，恕我直言。
我正在制作的应用程序与典型的电子商务应用程序非常不同。我在 PHP 中找到的唯一可能的现有解决方案是 Magento，但它似乎相当复杂，而且对我来说学习它然后从头开始制作自己的解决方案同样困难/耗时。
@Cobby，很公平，您比任何人都更了解您的需求，但恕我直言，如果您觉得学习 Magento 很复杂，那么编写自己的电子商务应用程序不是我的事d 推荐。确实有数以万计的开发人员和架构师时间投入到像 Magento 这样的应用程序中，并且在此过程中留下了很多战斗伤痕。当您处理客户或您客户的钱时，我宁愿让其他人在过去犯过这些错误，而不是我......

标签： php database-design magento entity-attribute-value doctrine-orm

【解决方案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 模块，该模块接受结构化数据并将其传递到应用程序的模型层以将其持久保存到数据库中。这确实增加了您的复杂性。

【讨论】：

我不认为性能会是一个主要问题，Doctrine 2 已经有一个查询缓存，另外我将实现我自己的级别。此外，重要的是要记住属性仅具有主要用途： 1. 过滤产品列表 2. 显示在产品页面上。属性中包含的数据只是元数据，不是应用程序运行所必需的。我猜它们有点像标签，在这种情况下 EAV 似乎很实用。
@Cobby Jonathan 关于缓存支架的观点。您如何为过滤器生成总计？您如何有效地为大量客户提供页面？如果您坚持自己构建它，请至少帮自己一个忙，并查看 Magento 对其 EAV 系统所做的更改以允许扩展。
只是扮演魔鬼的拥护者 - 我对 EAV 的感受完全一样：weblogs.sqlteam.com/davidm/articles/12117.aspx#42216 不是唯一一个有同样感觉的人：activecodeline.net/f-magento-eav
EAV 模型的一个优点是通常可以在不更改数据库模式的情况下实现对模式的更改。这很重要，因为在 MySQL ALTER TABLE 语句中锁定表以防止模式更改期间的所有读取和写入。因此，如果您需要更改大型表上的模式，这可能会导致锁定问题并在 ALTER TABLE 运行时可能会出现中断。（想想非常大且关键的表，例如电子商务网站上的客户或产品）。
@JimOHalloran，在锁定是一个严重问题的生产环境中，拥有主/从设置、更改从属、重新同步到主然后交换主/从是非常标准的并遵循相同的过程。当两个数据库在不同的结构上运行时，您可能需要编写自己的工具来同步它们，但这会非常简单。

【解决方案2】：

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

【讨论】：

是的，我已经审查了他们的数据库设计，这就是我建立原型的基础。我的问题不是关于 EAV 的实施......我已经知道如何使用它。我的问题是关于在生产环境中使用 EAV 的架构实用性。

【解决方案3】：

我建议您仔细研究带有 OXM 插件的 Doctrine 2 ORM (https://github.com/doctrine/oxm)。它将以不同的属性解决您的问题。当然，您将需要为可搜索的自定义属性建立索引，但我认为这不会有问题:)

如果您不关心社区成员的数量，那么您也可以使用 MongoDB。

【讨论】：