从高度事务性数据库中仅将Delta加载到分析数据库中的最佳方法是什么？
注意： 我们有一个高度事务性的系统，我们正在构建一个分析数据库。目前，我们正在从分析数据库中删除所有事实和维度表，并加载整个＆＃34;处理过的＆＃34;午夜的数据。这种方法的问题在于，我们每次都会一次又一次地加载相同的数据以及在特定日期添加/更新的少数新数据。我们需要加载＆＃34; Delta＆＃34;单独（新插入的行和更新的旧行）。有效的方法吗？
答案 0 :(得分：0)
在不知道细节的情况下很难说出某些内容，例如数据库模式，数据库引擎......但对我来说最自然的方法是使用时间戳。此解决方案假定从事务DB加载/迁移到分析数据库中的实体（表中的单个记录或相关记录组）具有时间戳。
此时间戳表示上次创建或更新给定实体的时间。在加载/迁移数据时，您应该仅考虑每个时间戳＆gt;的这些实体。上次迁移的日期。这种方法具有这种优点，非常简单，不需要任何特定工具。问题是你的数据库中是否已经有时间戳。
另一种方法可能是利用某种变更跟踪机制。例如，MMSQL服务器有类似的东西（见article）。但是，我必须承认我从未使用它，所以我不确定它是否适用于这种情况。如果您的数据库不支持更改跟踪，您可以尝试基于触发器自行创建它，但通常情况下这并不容易。
答案 1 :(得分：0)
我们需要单独加载“Delta”（新插入的行和已更新的旧行）。有效的方法吗？
您忘记了已删除的行。这就是问题的症结所在。在每个表上都有一个updated_at字段并且轮询updated_at > @last_poll_time的行或多或少有效，但是这样的轮询不会为您提供事务一致的图像，因为每个表都在不同的时刻进行轮询。跟踪已删除的行会导致应用/数据模型层出现复杂情况，因为行必须在逻辑上删除（is_deleted）或移动到存档表（对于每个表！）。
另一种解决方案是在数据库中编写触发器，将触发器附加到每个表，并让触发器将table_history写入发生的更改。同样，每个表的 。众所周知，这些解决方案很难在架构更改（添加，修改，删除表等等）的情况下长期维护。
但是有数据库特定的解决方案可以提供帮助。例如，SQL Server有Change Tracking和Change Data Capture。这些可用于构建维护分析数据仓库的ETL管道。但是，数据库架构更改仍然很痛苦。
没有银弹，没有精灵尘埃。