我正在构建一个需要可扩展数据模型的新系统。它非常复杂，但是系统中需要这种结构的部分与电子商务系统的产品部分非常相关，所以我将以此为例。
想象一组公司。每个公司都有一系列的产品，这些产品有一些基本属性，如name、sku、description、price等。除了这些基本属性，公司应该能够创建n自定义产品属性，这属于公司(即Foo Corp.不应该能够看到Acme Inc.的自定义属性)。除此之外，每个公司都应该能够将这些属性转化为每个产品;因此，每个自定义属性值基本上都是由attribute, product, language和value构建的。
我确实理解EAV结构是一种反模式，如果您存储了固定数量的属性，并且需要扩展属性数量的人不是系统的所有者。
所以我的问题是——你将如何做到这一点?在这种情况下EAV结构真的是反模式吗?Magento是使用这种设计的典型例子，看起来就像他们创造了一个怪物，并不得不通过实现扁平索引表来"修复"它。但是，是否有其他数据库设计模式允许这种程度的灵活性呢?
理解为什么EAV经常被认为是一种反模式，以及这些批评如何适用于您的情况是很有用的。理解为什么这么多人被EAV所吸引，以及他们从中看到了什么积极的好处，这也很有用。
大多数EAV数据库的最大问题是几乎不可能编写任何系统和集成的提取或报告系统，以便将数据转化为有用的信息。
如果在设计良好的关系数据库中提供管理良好的数据，则可以在不到一小时的工作中开发相同类型的报告，而在EAV数据库中则需要数周的时间。原因是这些数据基本上是未经分析的数据，被存储时没有考虑其固有的逻辑结构。
事实证明，这与其他一些人被EAV吸引的原因非常密切相关。你可以完全绕过数据分析。逻辑数据库的设计实际上是自动的，因为所有EAV数据库都具有相同的表结构。当你建造了一个，你就建造了所有的。
这为您提供了在任何可能考虑的情况下寻找的一些事情的处理。数据库的逻辑结构真的是动态的和不可知的吗?还是因为日程安排没有时间进行数据分析和数据库设计，人们就直接得出了这个结论?
数据将如何使用?人们是否期望对数据库中的数据进行传统意义上的检索?或者他们打算把每一次尝试的检索都当作对未知领域的探索?
在你的特殊情况下，我会问，即使每个公司都有自己的产品和属性知识库，但在某个"重要"人物要求跨公司合并产品数据之前，会有多长时间?如果这真的不会发生，也许你会没事的。如果没有，您最好在管理层意识到使用这些数据有多么困难之前离开。