修改后的EAV Schema如何有效管理历史数据？

通过修改后的 EAV 数据库设计有效管理历史数据

简介

虽然 EAV（实体-属性-值）数据库经常因设计缺陷而受到批评，但结构良好的 EAV 模式为跟踪历史数据并简化 SQL 和键值系统之间的数据交换提供了实用的解决方案。

用于历史数据管理的增强型 EAV 架构

为了克服常见的 EAV 限制并优化历史数据处理，提出了一种修改后的模式。这种方法按类型对实体属性进行分类，从而实现特定属性数据的高效存储和索引。

数据库架构

该架构包含多个表：

• entity_type： 存储基本实体类型（例如“产品”、“用户”）。

• 实体：将实体链接到其相应的实体类型。

• attr: 使用元数据（名称、类型）定义实体属性。

• attr_option, option: 处理基于选项的属性及其值。

• attr_int、attr_datetime、...: 不同属性类型（整数、日期时间等）的专用表。

• attr_relation：管理实体之间的外键关系。

示例查询

以下 SQL 查询说明了数据检索：

• 检索实体类型：

  <code class="language-sql">  SELECT * FROM entity_type et LEFT JOIN entity e ON e.entity_type_id = et.id WHERE e.id = ?</code>

• 检索实体属性：

  <code class="language-sql">  SELECT * FROM attr WHERE entity_id = ?</code>

• 检索最近的属性值：

  <code class="language-sql">  SELECT * FROM attr_option WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1  -- For single-value attributes
    SELECT * FROM attr_int WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1   -- For integer attributes
    SELECT * FROM attr_relation WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1 -- For relational attributes
    ...</code>

• 检索实体关系：

  <code class="language-sql">  SELECT * FROM entity AS e
    LEFT JOIN attr_relation AS ar ON ar.entity_id = e.id
    WHERE ar.entity_id = 34 AND e.entity_type = 2;</code>

潜在挑战

尽管有所改进，这种修改后的 EAV 方法仍面临一些挑战：

• 性能：检索属性值可能需要多个查询，可能会影响性能。
• 维护：跨单独表管理各种属性类型会增加维护复杂性。
• 自定义：高级操作，例如联接或聚合，可能需要自定义代码开发。

以上是修改后的EAV Schema如何有效管理历史数据？的详细内容。更多信息请关注PHP中文网其他相关文章！