EAV数据库模式

Question

我有一个超过10万条记录的数据库，包含许多类别和不同属性的项目。所有数据都存储在EAV中。

如果我尝试打破这种模式并为每个类别创建一个唯一的表格，这是需要避免的吗？

是的，我知道可能会有很多表格，并且如果我想要添加额外的字段，我需要修改它们，但这样做是否不好？

我也读到过，表格越多，数据库将填充更多的文件，这对任何文件系统都不好。

有什么建议吗？

- GLO

Answer 1

作为数据库设计中的主要结构，当数据增长时，该结构将会失败。当您需要查询报告时，您会知道数据库模式不适合业务模型。EAV需要许多变通和非本地数据库功能才能获得合理的报告。例如，即使是最小的查询，您也需要不断创建交叉表/枢轴查询。将EAV转换为可查询格式的所有处理都会消耗CPU周期，并且极易出错。此外，数据的大小呈几何级数增长。如果您有10个属性，在标准设计中的10行将生成100个EAV行。100个标准行相当于1000个EAV行，依此类推。

数据库管理系统旨在处理大量的表格，这不应该成为一个问题。

可以创建混合解决方案，其中EAV结构是解决方案的一部分。但是，规则必须是您永远不能包含查询[AttributeCol] = 'Attribute'。即您不能过滤、排序或限制任何属性的范围。您不能在报告或屏幕上的任何特定位置放置特定的属性。它只是一块数据。结合良好的系统其余部分的模式，具有存储数据块的EAV可能会很有用。使其正常工作的关键是自己和开发人员之间的执行力，永远不要越过过滤或排序属性的界限。一旦您走上黑暗之路，它将永远支配着您的命运。

- Thomas

Answer 2

有一些数据库引擎是专为运行EAV模型而设计的。我不知道它们是什么，所以无法推荐其中一个。但是将EAV模型强行塞入关系型引擎中，这样做注定会导致灾难发生。灾难肯定会发生，只是时间的问题。

也许你的数据大小足够小，你的查询也足够简单，这种方法可能起作用，但这种情况很少见。

- Stephanie Page

Answer 3

EAV数据库模式非常灵活，可以添加更多关系型数据库的“列”，但代价是降低查询性能并失去保存在关系数据库模式中的业务逻辑。

因为必须创建多个视图来实际旋转结果，如果表包含数十亿行，则会导致性能问题。EAV模式的另一个特点是，当您将数据表与元数据表连接时，始终会进行查询，并且可能会在同一数据表上进行多个连接。

这是基于我的经验。

- zs2020

Answer 4

我大约4年前在构建一个关于e-learning的创作系统时采用了这种方法。当时我不知道我正在做EAV，但我认为我很聪明，只使用了名称/值类型对。我想我会有更多的记录，但是减少了重新设计，因为每次有变更请求时，我都非常疲倦地调整左侧的列。

我首次测试了在一个表中构建系统层次结构的方法。通过级别整数链接回它们的主键，这个系统执行得非常好，有大约4个项目，25个产品和4到5个工具。

我一直记录通过系统传递的资产，这意味着FLV文件、SWF、JPG、PNG、GIF、PDF、MP3等...以及与它们相关的所有mime类型特定信息。每个文件上有4到10个属性。它总共有8百万个“资产数据”记录，而我们大约有80万个资产（估计）。

我收到了一个请求，要求将所有信息放入报表列中。SQL语句必须在自身上进行多个表连接，更不用说如果他们想知道内容所用的产品或项目，它就是一堆JOIN。

从更精细的角度来看，运行得很好。从Excel报表的角度来看，系好安全带。我通过对反映以报告方式展示的数据的表进行快照来缓解这一点，但编译该信息需要一段时间，这要求我将其卸载（SQL Dump）到另一个服务器上。

我发现自己问是否这样做是正确的，对于这个项目，我可以说在这个请求的大规模报告之前，“是”。但是它使服务器非常努力地协调所有工作。实际上取决于他们进行查询的深度级别。

自从2002年以来，我就开始涉及SQL，并将其用于支持工具，但没有大规模的生存能力。如果它是一个更大的百万人，千兆字节+数据库，我可能会拔掉头发。

特别说明：我发现这个系统在RedHat上运行，是32位的。许多PHP处理线程无法在超过1个CPU核心上运行，而服务器还有7个多余的核心空闲！在正确配置的64位系统中，这台机器上花费45分钟运行的查询实际上可以在14-25秒内运行。在考虑性能时也需要思考这一点。

- Mark