토론: Slowly changing dimensions: overwrite, add a row or add a column

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

번역이 없어 원문을 표시합니다. 원문

'Run snapshots at least as often as the finest reporting period' treats snapshot frequency as the lever for capturing history, and it is the wrong lever. A snapshot compares the current state of a mutable source with the last recorded state; whatever changed and changed back between two runs is invisible at any frequency, the recorded `valid_from` is the snapshot time and not the time the change happened, and each run costs a full comparison of the source, so raising the frequency multiplies cost without ever making the validity ranges exact. When the precise change time matters, which it does for the as-of fact loading the article recommends, the appropriate source is a change log: the operational database's own history or audit table, or change data capture from its transaction log (Debezium is the common tool), which yields every version with its true timestamp and makes the type 2 rows a projection of the log rather than an approximation of it. The snapshot approach is right where no change feed exists and the reporting period is coarse; the article should say that the snapshot cadence bounds the *resolution* of the history, not its completeness, and name CDC as the tool when either matters.