Thema: data-modelling
-
Eine Append-only-Zeitreihentabelle in PostgreSQL entwerfen
Messwerte in einer nach Zeitbereich partitionierten Tabelle mit timestamptz speichern, einem zusammengesetzten Schlüssel aus Serie und Zeit, Indizes passend zum Abfragemuster (B-Tree je Serie, BRIN für zeitliche Scans über die gesamte Tabelle) sowie Aufbewahrung durch Abtrennen und Löschen von Partitionen statt DELETE; die Entscheidungen ergeben sich daraus, dass Zeilen in zeitlicher Reihenfolge ankommen und in ganzen Zeitscheiben wieder verschwinden.
-
Langsam veränderliche Dimensionen: überschreiben, eine Zeile hinzufügen oder eine Spalte hinzufügen
Ändert sich ein Dimensionsattribut (eine Kundin zieht um, ein Produkt wird neu klassifiziert), überschreibt Typ 1 den Wert und verliert die Historie, Typ 2 fügt unter einem neuen Surrogatschlüssel eine neue Zeile mit Gültig-ab- und Gültig-bis-Datum sowie einem Aktuell-Flag hinzu, und Typ 3 behält den vorherigen Wert in einer zusätzlichen Spalte. Snapshot-Werkzeuge setzen Typ 2 um, indem sie bei jedem Lauf einen Aktualisierungszeitstempel oder eine Menge von Spalten vergleichen.
-
JSONB-Spalten: wofür sie taugen und wann eine eigene Spalte besser ist
jsonb speichert geparstes JSON in einer binären Form, die sich mit GIN indexieren und über Containment- und Pfadoperatoren abfragen lässt; es eignet sich für spärliche, extern definierte oder tatsächlich variable Attribute. Daten mit fester Struktur, Daten, die Constraints, Fremdschlüssel oder Aktualisierungen einzelner Felder benötigen, sowie grosse, häufig geänderte Dokumente gehören in gewöhnliche Spalten.
-
Einwilligungs- und Präferenzdatensätze als Daten: was wann und über welche Oberfläche gewählt wurde
Die Entscheidungen einer Person als Append-only-Ereignisse modellieren (betroffene Person, Zweck, Entscheidung, Zeitpunkt, Quelle, Textversion) mit einer abgeleiteten Sicht auf den aktuellen Zustand, die jeder Konsument am Verwendungsort liest; ein Boolean in der Benutzerzeile kann nicht beantworten, was zum Zeitpunkt einer bestimmten Aktion vereinbart war oder welche Benutzer ein Banner-Fehler betraf.
-
Datenminimierung als Disziplin für Schema und Protokollierung
Nur die Personendaten speichern, die ein Feature benötigt, in der gröbsten Genauigkeit, die dem Zweck genügt, und Kennungen durch Allowlisting von Feldern aus Logs heraushalten; jede Spalte, jedes Logfeld und jeder abgeleitete Speicher, der Personendaten trägt, ist eine Designentscheidung mit einem Zweck, einer verantwortlichen Person und einem Ablaufdatum, kein Standardfall.
-
Soft Deletes versus Archivtabellen
Ein Soft Delete behält die Zeile mit einer Markierung deleted_at, sodass jede Abfrage sie herausfiltern muss und jede Unique-Constraint zu einem partiellen Index werden muss; eine Archivtabelle verschiebt die Zeile aus der Live-Tabelle, sodass Live-Abfragen einfach bleiben und die Historie an einem Ort liegt. Die Wahl danach treffen, wer gelöschte Daten wie oft liest, und die Entscheidung in Constraints und Views verankern statt in jeder Abfrage.
-
Normalising to third normal form and choosing when to denormalise
Normal forms remove repeating groups and facts stored in more than one place; third normal form means every non-key column depends on the key and nothing else. Normalise by default for transactional data and denormalise only in named, derived columns whose source of truth stays normalised.
-
Declarative constraints in PostgreSQL: CHECK, UNIQUE and foreign keys with ON DELETE
Constraints make the database reject invalid states for every writer, not just the application: CHECK for per-row rules, NOT NULL for required values, UNIQUE for identity, and foreign keys with an explicit ON DELETE action. Choosing the referential action and indexing the referencing column are the two decisions most often skipped.
-
Star schema basics: facts, dimensions and declaring the grain
A star schema stores measurements in fact tables and descriptive context in dimension tables linked by keys; the design starts by declaring the grain, what one fact row represents, because every measure and dimension must be consistent with it. Fully additive measures sum across any dimension, semi-additive ones not across time, and ratios must be stored as their components.
-
Pseudonymisation versus anonymisation as engineering techniques
Pseudonymisation swaps direct identifiers for tokens while keeping a way back (a key or a lookup table) and leaves one record per person; anonymisation aims to remove the association between records and people for everyone. Use keyed HMAC per purpose for pseudonyms, and treat a pseudonymised table as personal data with quasi-identifiers still in it.
-
Identity columns, sequences and why generated IDs have gaps
Identity columns are the standard way to auto-number rows in PostgreSQL; they draw from a sequence whose values are handed out outside transaction control, so rollbacks, crashes, caching and ON CONFLICT inserts leave gaps. Gaps are normal; a gapless number needs a separate, serialised counter.
Maschinenlesbar: JSON