EAV数据库计划

Question

我有一个数据库与更多的100K记录。 许多类别和许多项目（每个类别具有不同的属性） 所有内容都存储在EAV中。

如果我试图打破这种方案和创建任何目录的唯一表 是将我必须避免的东西吗？

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

我也读过，我有很多表，数据库将填充更多的文件 ，这是不适合任何文件系统。

有什么建议吗？

Answer 1

EAV DB模式是增加更多的关系型数据库的“列”，但在日益恶化的查询性能，失去这是保存在关系数据库模式的业务逻辑的成本非常灵活。

因为你必须创建实际转动的结果，这将导致性能问题，如果表中包含数十亿行的多个视图。 EAV模式的另一个本质是，当您将数据表与元数据表连接在一起时，总是会进行查询，并且同一数据表上可能会有多个连接。

这是基于我的经验。

Answer 2

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

数据库管理系统是设计来处理大量的表格和这不应该是一个隐忧。

有可能创建一个混合解决方案，其中EAV结构为部分的解决方案。但是，该规则必须是您永远不能包含查询[AttributeCol] = 'Attribute'。即，你永远不能过滤，排序，限制任何属性的范围。您不能在报告或屏幕上的任何位置放置特定的属性。它只是一个数据的一块。结合系统其他部分的良好模式，使用存储一组数据的EAV可能很有用。实现这一目标的关键是您自己和执行者之间的执行力度，而且绝不会越过对属性进行过滤或排序的行。一旦你走下黑暗的道路，它将永远支配你的命运。

Answer 3

有数据库引擎专用于运行EAV模型。我不知道他们，所以我不能推荐一个。但将EAV模型推入关系引擎是一种灾难。灾难会发生，这只是时间问题。

这可能是因为你的数据将保持足够小，和你的查询很简单这个工作，但是这是很难实现的。

Answer 4

我承担了一个创作系统我建立了电子学习大约4年前，这一做法。我当时并不知道自己在做EAV，但我认为我只是使用名称/值类型对而非常狡猾。我想我会增加记录，但重新设计的次数会减少，因为每当我们有变更请求时，我都很厌倦将列调整到左侧。

我做了我的第一个测试，在一张表中构建出系统的层次结构。这表现很好，大约有4个项目，25个产品和4到5个工具，每个工具都分配了通过链接回主键的层级整数。

我一直在记录通过系统传递的资产，这意味着FLV文件，SWF，JPG，PNG，GIF，PDF，MP3等......以及关于它们的所有mime类型细节。这范围从每个文件只有4到10个属性。其总计高达800万的“资产数据”记录，因为我们拥有约80万资产（est）。 我有一个请求将所有信息放入报告的列中。 SQL语句必须自行完成大量的表连接，更不用说如果他们想知道它使用的内容，产品或项目只是一连串的JOIN。

从细化的角度看，效果很好。从Excel报告的角度来看，系上安全带。我已经通过将快照发送到按照某人在报告中想要的方式反映数据的表来缓解它，但编译该信息需要一段时间才能将其卸载（SQL Dump）到另一个服务器上。

我发现我自问：这是否是正确的做法，对于这个项目，我可以说这个请求的大规模报告“是”。但是这会让服务器的流汗很糟糕，并且将其全部关联起来。真的取决于他们所做的深层次的查询。

自从我从2002年开始涉足SQL并将其用于支持工具后，它在任何规模上都没有生存下来。如果它是一个更大的人，terabyte +数据库我可能会拉我的头发。

特别提示：我发现这个系统在RedHat上，它是32位的。大多数PHP处理线程无法在超过1个CPU内核上运行，并且服务器还有7个内核处于空闲状态！在这台机器上运行最多需要45分钟的查询，实际上可以在正确配置的64位系统上运行14到25秒。在考虑性能时也需要思考。