父实体为带历史表的SCD Type 4时，子实体需建历史表吗？

核心思路：基于配料变更追踪而非全量复制 #

不需要为每个旧版本食谱全量复制配料，而是通过配料的版本标识+变更快照实现高效版本控制，以下是两种可行方案：

方案1：为配料表添加版本生命周期字段 #

修改原ingredient表结构，新增用于追踪配料生效周期的字段：

CREATE TABLE ingredient (
    recipe_id INT,
    ingredient_id INT PRIMARY KEY, -- 为配料分配独立ID，追踪全生命周期
    other_stuff TEXT,
    active_version_start INT NOT NULL, -- 配料生效的起始食谱版本
    active_version_end INT, -- 配料失效的终止食谱版本（NULL表示当前有效）
    change_type VARCHAR(10) NOT NULL, -- 变更类型：ADD/UPDATE/DELETE
    FOREIGN KEY (recipe_id) REFERENCES recipe(id)
);

工作流程： #

1. 发布食谱新版本时，仅处理发生变更的配料：
   • 新增配料：active_version_start设为当前食谱版本，active_version_end留空，change_type标记为ADD
   • 修改配料：将旧配料的active_version_end设为当前版本-1，新增一条记录存储修改后的数据，active_version_start设为当前版本，change_type标记为UPDATE
   • 删除配料：将目标配料的active_version_end设为当前版本-1，change_type标记为DELETE
2. 查询指定版本的食谱配料时，通过以下条件过滤：

   SELECT * FROM ingredient
   WHERE recipe_id = ? 
     AND active_version_start <= ? 
     AND (active_version_end IS NULL OR active_version_end >= ?)
   

优势： #

• 仅存储变更记录，避免未变更配料的重复存储，节省空间
• 无需额外历史表，维护成本更低
• 外键关联逻辑清晰，recipe_id直接关联recipe表，版本字段通过业务逻辑关联对应食谱版本

方案2：拆分当前表与变更日志表 #

将配料数据拆分为两张表，分离当前状态与历史变更：

1. ingredient_current：存储当前所有生效的配料，结构与原ingredient一致，直接关联当前版本的recipe表
2. ingredient_change_log：仅记录配料的变更历史，结构示例：

   CREATE TABLE ingredient_change_log (
       log_id INT PRIMARY KEY AUTO_INCREMENT,
       recipe_id INT,
       recipe_version INT,
       ingredient_id INT,
       old_value JSON, -- 可选：存储变更前的完整数据
       new_value JSON, -- 可选：存储变更后的完整数据
       change_type VARCHAR(10),
       change_timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
       FOREIGN KEY (recipe_id) REFERENCES recipe(id)
   );
   

工作流程： #

1. 发布食谱新版本时，仅将变更的配料写入ingredient_change_log，同时更新ingredient_current为最新状态
2. 回溯旧版本配料时，以ingredient_current为基准，按版本倒序应用ingredient_change_log中的变更记录，还原出指定版本的配料集合

优势： #

• ingredient_current始终保持精简，当前版本查询性能最优
• 变更日志仅存储差异，存储空间占用小
• 适合当前版本查询占比极高、历史回溯需求较少的场景

方案选择建议 #

• 若需要频繁查询历史版本的完整配料集合，优先选方案1，可直接通过SQL过滤得到结果，无需计算还原
• 若当前版本查询占比极高、历史回溯需求少，优先选方案2，能最大化主表的查询性能

内容的提问来源于stack exchange，提问作者Henry