EAV 数据库设计是高效历史数据管理的正确解决方案吗？

EAV 数据库设计：历史数据管理方法

实体-属性-值 (EAV) 数据库模型虽然经常因潜在的数据完整性和报告挑战而受到批评，但它在跟踪历史数据以及桥接 SQL 和键值存储环境方面具有优势。 本文探讨了一种改进的 EAV 方法来缓解这些问题。

按数据类型组织实体属性

传统 EAV 的一个关键改进是根据数据类型分离实体属性。 这有利于关系的管理（例如，“belongsTo”、“has”、“hasMany”、“hasManyThrough”），并允许对属性和实体进行正确的索引。

建议的关系模式

提出以下关系数据库模式：

<code class="language-sql">entity_type {
    id,
    type,       -- e.g., "product," "user"
    created_at
}

entity {
    id,
    entity_type_id,
    created_at
}

attr {
    id,
    entity_id,
    type,
    name,
    created_at
}

option {
    id,
    attr_id,
    entity_id,
    multiple, -- Allow multiple values
    name,
    created_at
}

attr_option {
    id,
    attr_id,
    entity_id,
    option_id,
    option,
    created_at
}

-- Additional tables for various attribute types (e.g., attr_int, attr_datetime)</code>

追踪历史数据

此架构通过添加新属性值并利用时间戳来识别最新更改来实现历史数据跟踪。 这避免了数据更新的需要，同时保留了完整的修改历史记录。

示例查询

说明性查询演示数据检索：

• 实体类型检索：

  <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 = ? AND multiple = 0 ORDER BY created_at DESC LIMIT 1  -- Single Value
    SELECT * FROM attr_int WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1                  -- Integer Value
    -- ... other attribute type queries</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 数据库设计是高效历史数据管理的正确解决方案吗？的详细内容。更多信息请关注PHP中文网其他相关文章！