EAV-在电子商务案例中，它真的是反模式吗？

Question

我正在构建一个新系统，该系统将需要可扩展的数据模型。它非常复杂，但是需要这种结构的系统部分与电子商务系统的产品部分非常相关，因此我将以此为例。

想象一下一组公司。每家公司都有一系列的产品，其中有一些基本的属性，如name，sku，description，price等。除了这些基本属性，公司应该能够创建n定制的产品属性，属于公司（即美孚公司不应该能够看到Acme Inc.的自定义属性）。除此之外，每个公司都应该能够为每个产品转换这些属性；所以每个自定义属性值基本上从一个构造attribute，一个product，language和一个value。

我确实知道，如果您存储固定数量的属性，而需要扩展属性数量的不是系统所有者，则EAV结构是一种反模式。

所以我的问题是-您将如何实现？在这种情况下，EAV结构真的是反模式吗？Magento是使用这种设计的人的经典示例，似乎他们建立了一个怪物，不得不通过实现平面索引表来“修复”它。但是，是否还有其他数据库设计模式可以实现这种灵活性？

Answer 1

了解为什么EAV经常被认为是反模式，以及这些批评对您的案例的适用程度很有用。了解为什么会有如此多的人被EAV吸引，以及他们从中看到了什么积极的益处也很有用。

大多数EAV数据库的最大问题在于，几乎不可能编写任何类型的系统且集成的提取或报告系统，以将数据转化为有用的信息。

如果在精心设计的关系数据库中提供管理良好的数据，则可以在不到一个小时的工作中开发出相同类型的报告，而在EAV数据库中可能要花费数周的时间才能开发出该报告。原因是该数据从根本上来说是未经分析的数据，已存储，而不考虑其固有的逻辑结构。

事实证明，这与其他人被EAV吸引的原因密切相关。您可以完全绕过数据分析。由于所有EAV数据库都具有相同的表结构，因此逻辑数据库设计实际上是自动的。构建一个后，您就构建了所有这些。

这使您可以在任何情况下都可以考虑一些事项。数据库的逻辑结构是否真正动态且不可知？还是因为进度表没有时间进行数据分析和数据库设计，人们才刚刚得出这个结论吗？

数据将如何使用？人们是否期望进行传统上期望的数据库数据检索？还是他们打算将每次尝试的检索视为对未知领域的探索？

在您的特定情况下，我想问“重要的”某人要求跨公司合并产品数据要花多长时间，即使它们每个人都维护自己的产品和属性知识库。如果那真的不会发生，也许你会没事的。如果没有，您最好在管理层意识到使用这些数据有多困难之前继续前进。