从高度事务性的数据库仅将增量加载到分析数据库中的最佳方法是什么？
注意：我们有一个高度事务化的系统，我们正在从中建立一个分析数据库。目前，我们正在从分析数据库中擦除所有事实和维度表，并在午夜加载整个"已处理"数据。这种方法的问题在于，我们每次都一次又一次地加载相同的数据，以及在特定日期添加/更新的少数新数据。我们需要单独加载"增量"（新插入的行和更新的旧行）。有什么有效的方法可以做到这一点吗？
不知道细节就很难说出一些东西，例如数据库模式、数据库引擎......然而，对我来说最自然的方法是使用时间戳。此解决方案假定从事务数据库加载/迁移到分析数据库的实体（表中的单个记录或一组相关记录）具有时间戳。
此时间戳表示上次创建或更新给定实体的时间。加载/迁移数据时，应仅考虑每个时间戳>上次迁移日期的这些实体。这种方法具有非常简单的优点，不需要任何特定的工具。问题是您的数据库中是否已经有时间戳。
另一种方法可能是利用某种更改跟踪机制。例如，MMSQL服务器也有类似的东西（请参阅这篇文章）。但是，我不得不承认我从未使用过它，所以我不确定它是否适合这种情况。如果您的数据库不支持更改跟踪，您可以尝试根据触发器自行创建它，但一般来说，这并不容易做到。
我们需要单独加载"增量"（新插入的行和更新的旧行）。有什么有效的方法可以做到这一点吗？
您忘记了已删除的行。这就是问题的症结所在。在每个表上都有一个updated_at字段并轮询具有updated_at > @last_poll_time的行或多或少有效，但像这样的轮询不会给你一个事务盟友一致的图像，因为每个表都是在不同的时刻轮询的。跟踪已删除的行会在应用程序/数据模型层引起复杂性，因为必须逻辑删除行（is_deleted）或移动到存档表（对于每个表！
附加到每个表，并将触发器写入table_history发生的更改。同样，对于每个表。众所周知，这些解决方案在模式更改（添加、修改列、删除表等）的情况下难以长期维护
但是有一些特定于数据库的解决方案可以提供帮助。例如，SQL Server具有更改跟踪和更改数据捕获。可以利用这些来构建维护分析数据仓库的 ETL 管道。但是，数据库架构更改仍然很痛苦。
没有灵丹妙药，没有小精灵尘埃。