我已经开发了几个应用程序，并与其他在数据仓库的几个细节方面遇到问题的开发人员进行了交谈。
我看到的主要问题是关于操作数据存储中的变更数据检测 (CDC)。 更新和硬删除显然很难在操作数据存储中检测到。
可以通过在每个表上插入触发器来处理更新，该触发器会使用当前时间戳自动更新 updated_at 列。但删除更难——一种解决方案是在其中放置一个触发器，以更新带有已删除 ID、表和时间戳的审计表。
使用触发器似乎是进行更改数据检测的最合理方法，但我看到的另一种选择是解析数据库事务日志文件，尽管这可能会使更新操作数据存储数据库变得更加困难。
我的问题是，人们通常如何处理这个问题？我做了一些研究，看起来很多做数据仓库的公司都在推出他们自己的次优解决方案。
我见过的另一个避免与 CDC 相关问题的解决方案是每隔一段时间简单地重建整个（或与源数据相关的部分）数据仓库，这将确保所有数据都是最新的并且没有错误在对操作数据存储执行 CDC 的代码中。
这是我通常处理更新和删除的方式。
源系统中的更新
一些 DBMS 提供一列，如果将其添加到所有表中，则为仓库提供始终增加的唯一标识符。SQL Server 有 TIMESTAMP 列。Oracle 提供了 ora_rowscn 伪列，擅长块级。
虽然我没有使用它，但 Postgres 有 xmin 伪列，我相信它可以以类似的方式使用。对此存在一些担忧，但我认为出于数据仓库变更跟踪的目的，它可能会奏效。
源系统中的 UPDATE 触发器以更新上次修改日期是另一种选择。如果您在进行提取时正在对 ODS 进行大量更新，请将此日期保持在非常高的精度，以降低“丢失”记录的风险。
源系统中的删除
至于删除的记录，我首选的解决方案是确保所有源表都有一个主键（最好是一列，尽管多列是可行的）。我每天将这一列的全部内容提取到一个阶段表中，然后识别与源相比目标表中“缺失”的行，更新目标记录上的“源已删除”标志或其他内容。我通常只对维度表执行此操作，因为即使原始事务已经消失，事实表也应该保留历史记录。
作为 postgresql 用户和开发人员，使用您所描述的触发器是--恕我直言--最好的方法。让数据库完成它的设计目的：管理和保护您的数据。使用更新日期和使用删除日期处理的逻辑删除可以更轻松地提供事务的历史跟踪。使用低负载时段将“已删除”数据移动到历史表有助于保持生产表的可管理性。
我认为在正确设计的数据仓库中不应该删除或更新事实表，只有插入。然后通过时间戳或通过一些顺序 ID 捕获插入应该是微不足道的。