database - EAV 数据库架构

Question

我有一个包含超过 100K 条记录的数据库。很多类别和很多项目(每个类别具有不同的属性)一切都存储在 EAV 中。

如果我尝试打破这个方案并为任何类别创建一个唯一的表格是我必须避免的事情吗？

是的，我知道我可能会有很多表，我需要修改它们如果我想添加一个额外的字段，但是这是错误的吗？

我还读到，我拥有的表越多，数据库中就会填充越多的文件这对任何文件系统都不利。

有什么建议吗？

Answer 1

作为数据库设计中的主要结构，该结构将随着数据的增长而失效。您知道数据库模式不适合业务模型的方式是当您需要针对它进行查询以进行报告时。 EAV 需要许多解决方法和非本地数据库功能才能获得合理的报告。也就是说，您不断地为最小的查询创建交叉表/数据透视表查询。获取 EAV 并将其置于可查询格式的所有处理都会消耗 CPU 周期，并且很容易出错。此外，数据量呈几何级数增长。如果您有 10 个属性，则标准设计中的 10 行将生成 100 个 EAV 行。 100 个标准行相当于 1000 个 EAV 行，依此类推。

数据库管理系统旨在处理大量表，这不应该是一个担心。

可以创建一个混合解决方案，其中 EAV 结构是解决方案的一部分。但是，规则必须是您永远不能包含查询 [AttributeCol] = 'Attribute'。也就是说，您永远不能过滤、排序、限制任何属性的范围。您不能将特定属性放置在报告或屏幕上的任何位置。它只是一团数据。结合系统其余部分的良好模式，拥有存储数据 block 的 EAV 可能很有用。使这项工作成功的关键是你自己和开发人员之间的强制执行，永远不要越过对属性进行过滤或排序的界限。一旦你走上黑暗的道路，它将永远主宰你的命运。