我已经在几个应用程序上工作过，并与其他开发人员讨论过有关数据仓库的几个细节。如何递增填充数据仓库？
我看到的主要问题是关于操作数据存储中的更改数据检测（CDC）。 更新和硬删除显然可能很难在操作数据存储中检测到。
可以通过在EVERY表上插入触发器来处理更新，该触发器会使用当前时间戳自动更新updated_at列。尽管删除更困难 - 一种解决方法是在触发器中更新一个删除了id的审计表，一张表和一个时间戳。
使用触发器似乎是最合理的方式来执行更改数据检测，但我已经看到的另一个选项是解析数据库事务日志文件，虽然这可能会更难以更新操作数据存储数据库。
我的问题是，人们通常如何处理这个问题？我已经做了相当多的研究，看起来好像很多做数据仓库的公司正在推出他们自己的次优解决方案。
我发现避免与CDC相关的问题的另一种解决方案是每隔一段时间简单重建一次ENTIRE（或与源数据相关的部分）数据仓库，这将确保所有数据是最新的并且在操作数据存储上执行CDC的代码中没有任何错误。
这是我通常处理更新和删除的方式。
更新源系统
某些DBMS的提供了一个列，其中，如果添加到所有的表，提供了一个唯一的标识符，始终是增加仓库。 SQL Server具有TIMESTAMP列。 Oracle提供了ora_rowscn伪列，这在块级别上很好。
虽然我还没有使用它，Postgres有xmin伪列，我相信它可以以类似的方式使用。有一些担心，但我认为数据仓库更改跟踪的目的，它可能会伎俩。
更新触发器在源系统中更新最后修改日期是另一种选择。保持这个日期的精确度非常高，以便在执行提取操作时正在运行ODS上的大量更新时减少“缺失”记录的风险。
删除在源系统
至于删除的记录，我的优选方案是，以确保所有的源表的主键（优选一列，尽管多是可行的）。我每天将该列的全部内容提取到阶段表中，然后确定目标表中与源相比“丢失”的行，更新“源删除”标志或目标记录上的某些内容。我通常只对维度表执行此操作，因为事实表应该保留历史记录，即使原始事务已经结束。
我认为不应该删除或更新正确设计的数据仓库中的事实表，只能插入。然后，通过时间戳或通过一些顺序ID来捕获插入应该是微不足道的。
我在说什么时候有人删除生产数据库中的记录，而不是数据仓库中的记录。 –
除非事实表是一个累积的快照事实......那么更新每天都会发生。 –
作为postgresql用户和开发人员，您所描述的使用触发器是--IMHO--最好的方法。让数据库完成它设计的任务：管理和保护您的数据。使用更新日期和使用删除日期处理的逻辑删除可以更轻松地提供事务的历史记录。使用低负载时间将“删除”的数据移动到历史表有助于保持生产表的可管理性。
作为附录：解析ODS日志文件通常是主要ETL供应商中的CDC工具所做的工作。解析日志并不是一件容易的事，我会推荐我提到的触发器或其他方法。 –
很好的回答ñ西！ –