关系型数据仓库中事件类数据的变更处理方案咨询

问题1：针对此类事件数据，使用技术起止日期（类似SCD2）是否存在弊端？ #

是的，这种方案存在明显不匹配场景的问题，主要弊端包括：

• 数据冗余：同一个access ID会生成多行仅结束日期不同的记录，随着访问事件量增大，存储成本和数据体积会不必要地膨胀。
• 分析复杂度提升：查询当前有效记录时需额外过滤end_date IS NULL或end_date > 当前日期，而此场景下大部分分析需求聚焦于事件的最终状态，多版本记录会给日常查询带来冗余步骤。
• 违背Inmon架构核心逻辑：Inmon架构强调数据仓库是面向主题的、稳定的集成数据集合，SCD2设计原本用于维度属性的缓慢变更（如客户信息更新），但访问事件属于事实事件，仅存在“未结束→已结束”的单次状态补全，并非维度属性的多次变更，用SCD2会混淆事实表与维度表的设计边界。

问题2：使用last update date列并更新现有记录是否更合适？ #

这种方案更贴合当前业务场景，原因如下：

• 匹配事件本质：访问事件是单次完成的动作，结束日期的补录只是对事件信息的完善，而非多次状态变更。每个access ID对应唯一记录，能保证数据简洁，符合事实表的设计逻辑。
• 适配Inmon架构：Inmon架构要求数据仓库层保持一致性与稳定性，这里的更新是对缺失信息的补全，而非频繁的属性变更，不会破坏数据仓库的稳定特性。last_update_date字段可有效追踪补录操作的时间，满足基础审计需求。
• 查询效率更高：无需过滤多版本数据，查询所有访问事件的当前状态时更直接，降低了分析层的复杂度。

额外注意事项 #

• 同步策略：需确保源系统的更新能精准同步到数据仓库，可基于源系统的更新时间戳或变更日志实现增量同步，避免遗漏补录操作。
• 审计扩展：如果业务需要追踪“结束日期从无到有”的具体变更过程，仅靠last_update_date无法记录变更细节，可额外建立变更审计表，记录access ID、变更字段、变更前后值、变更时间、操作人等信息，既保留主表简洁性，又满足深度审计需求。

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