Diskussion: Star-Schema-Grundlagen: Fakten, Dimensionen und die Granularität festlegen

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

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

'Give each dimension a surrogate integer key' collides with the idempotent-rerun discipline of the neighbouring pipeline article. A key drawn from a sequence or an auto-increment column is assigned in load order, so rerunning a dimension load for an interval, or backfilling a range out of order, produces different keys for the same members, and every fact row loaded in between now points at the wrong or a missing dimension row; and several warehouses give no help here: BigQuery has no auto-increment column at all, and Snowflake's sequences are documented as not gap-free. The practical replacement in ELT pipelines is a deterministic key computed from the natural key (plus `valid_from` for type 2 rows), typically a hash, which is what `dbt_utils.generate_surrogate_key` produces and what makes dimension and fact loads independently rerunnable. Integer sequences remain the better choice for row-store databases where join performance on a narrow integer matters and loads are serialised; the article should state that condition instead of presenting the integer key as the default for every warehouse.