Schlechte Daten kündigen sich nicht an. Ein Alter von 200 Jahren, eine doppelte Kundennummer, ein Ländercode, den es nicht gibt — im Quellsystem fällt das niemandem auf. Erst wenn der ETL-Lauf die Sätze in die strikt modellierte Zielschicht schieben will, bricht der Load ab: an einem CHECK, an einem UNIQUE-Index, an einem Fremdschlüssel. Datenqualität mit SQL prüfen heißt, genau … Weiterlesen
„Wir machen ETL.“ Der Satz fällt in fast jedem Daten-Team — und stimmt oft nicht. Wenn jede Transformation als Stored Procedure läuft, nachdem die Rohdaten bereits unverändert in eine Staging-Tabelle geladen wurden, dann ist das der Sache nach ELT. Das Etikett verdeckt, was wirklich passiert. Der Unterschied ETL vs. ELT entscheidet sich nicht an der Reihenfolge der Buchstaben, sondern … Weiterlesen
Eine PL/pgSQL-Funktion ohne Volatilitäts-Marker ist per Default VOLATILE. Das klingt harmlos, kostet aber real: Der Planer ruft die Funktion pro Zeile erneut auf, berechnet sie nie einmalig vorab und schließt sie aus jedem funktionalen Index aus. Der Schaden ist unsichtbar — bis dieselbe Abfrage auf einmal Sekunden statt Millisekunden braucht. Gute PL/pgSQL-Funktions-Konventionen fangen genau hier an: nicht beim … Weiterlesen
Eine Tabelle anzulegen dauert dreißig Sekunden – sich über ihren Namen, ihren Schlüssel und ihre Spaltentypen zu ärgern, dann zwei Jahre. Postgres-Tabellen-Konventionen nehmen diesen Ärger einmal vorne weg: konsistente Namen, ein vorhersehbarer Primärschlüssel, Datentypen ohne Überraschung und Audit-Spalten, die jede Zeile erklären. Ohne sie driftet ein Schema mit jeder neuen Tabelle weiter auseinander – und beim ersten … Weiterlesen
Eine KI schreibt dir eine Stored Procedure in Sekunden. Sie kompiliert, sie läuft – und sie sieht aus, als hätte sie ein Fremder geschrieben. Beim nächsten Artefakt sieht sie wieder anders aus. Generierter SQL-Code ist technisch korrekt, aber stilistisch beliebig – und ohne durchgesetzte Konvention driftet eine generierte Sammlung genauso auseinander wie eine, an der fünf Entwickler … Weiterlesen
Eine Stored Procedure, ein Migrations-Skript, eine komplexe Auswertung – Claude Code schreibt sie in Sekunden. Das ist der einfache Teil. Der schwere Teil beginnt danach: Generierter SQL-Code, der niemandem gehört, driftet genauso auseinander wie handgeschriebener – nur schneller, weil die KI auf Zuruf Hunderte Zeilen produziert. KI-gestützte SQL-Entwicklung ist erst dann ein Gewinn, wenn der generierte Code denselben … Weiterlesen
Wer eine Stored Procedure schreibt, schreibt sie für jemanden, der sie nicht kennt – meist für sich selbst, 18 Monate später, um 23 Uhr, während ein ETL-Lauf hängt. Lesbarkeit ist keine Kosmetik, sondern Debugging-Zeit. PostgreSQL zwingt einen zu fast nichts: Namen sind frei, Einrückung ist egal, ein RAISE EXCEPTION schluckt jeden inline-zusammengebauten Text. Genau deshalb driften Prozeduren-Sammlungen ohne Konvention innerhalb … Weiterlesen
Wer einmal eine CSV-Spalte mit gemischten Datums-Formaten in eine datetime-Spalte importieren musste, weiß: Datenqualität beginnt bei der Typ-Konvertierung. SQL Server lässt einen mit style-Codes alleine, sobald das Format vom Standard abweicht — TRY_CONVERT deckt die dokumentierten Formate ab, alles andere braucht eine eigene Funktion. Das nimmst du mit: Voraussetzung: SQL Server 2017+ (für TRY_CONVERT-Styles 23/126), für die Postgres-Brücke PostgreSQL 12+. Inhalt Überblick Die wohl herausforderndste Konvertierung … Weiterlesen
Datenqualität beginnt bei der Typ-Konvertierung — und bei bit-Spalten zeigt sich das schon beim Eingangswert: Yes/No-Informationen liegen in Legacy-Quellen in unterschiedlichsten Notationen vor (‚J‘, ‚Y‘, ‚ON‘, ‚1‘, ‚x‘, ‚-‚, …). SQL Servers eingebautes TRY_CONVERT(bit, …) deckt nur den Ziffern-Standard plus ‚true’/’false‘ ab — alles andere braucht eine eigene Konvertierungs-Funktion. Dieser Artikel beschreibt beides: was eingebaut funktioniert, wann eine fn_convert_bit-Funktion her muss und wie das Pendant in Postgres … Weiterlesen
Datenqualität bei Gleitkomma-Spalten ist eine eigene Disziplin — und TRY_CONVERT(float, …) hat ein paar Eigenheiten, die im Import-Pfad gerne übersehen werden: eine leere Zeichenfolge wird zu 0 (statt zu NULL), ein Komma als Dezimaltrennzeichen führt zu NULL, und selbst nach einer sauberen Konvertierung ergibt 2 + 3.4 – 3.4 – 2 als float nicht exakt 0. Dieser Artikel sortiert die Regeln, zeigt das sichere Konvertierungs-Pattern und macht … Weiterlesen
