PL/pgSQL-Funktionen mit Tabellen-Rückgabe — RETURNS TABLE, SETOF und wann eine View besser ist

Eine View ist die eleganteste Art, eine wiederkehrende Abfrage zu kapseln — bis zu dem Moment, in dem die Abfrage ein Argument von außen braucht. Eine View kennt keine Parameter. Sobald im WHERE ein Wert stehen soll, den der Aufrufer mitgibt, ist die tabellenwertige Funktion das Mittel der Wahl: eine Funktion, die statt eines einzelnen Werts eine ganze Ergebnismenge … Weiterlesen

Datentyp-Mapping SQL Server → PostgreSQL — was sauber konvertiert und was kippt

Eine Migration von SQL Server nach PostgreSQL scheitert selten am eigentlichen Kopieren der Daten. Sie scheitert an datetime, wo timestamp und timestamptz keine Geschmacksfrage sind, an bit, das kein boolean ist, und an money, das man in PostgreSQL besser gar nicht erst anfasst. Das Datentyp-Mapping SQL Server PostgreSQL entscheidet, ob die Daten sauber ankommen — oder still verfälscht werden, ohne dass eine einzige Fehlermeldung erscheint. Die … Weiterlesen

Datenqualität mit SQL prüfen — ein konfigurierbares Framework, das schlechte Daten generisch aufspürt

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

ETL vs. ELT — woran du erkennst, welches Muster du wirklich gebaut hast

„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

PL/pgSQL-Funktions-Konventionen — Volatilität, RETURNS und die Grenze zur Prozedur

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

Postgres-Tabellen-Konventionen — Naming, Keys und Audit-Spalten für ein konsistentes Schema

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

SQL-Konventionen mit Claude Code ableiten — der Generate-Refine-Derive-Loop

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

KI-gestützte SQL-Entwicklung mit Claude Code — Rules, Skills und Agenten, die Konventionen durchsetzen

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

SQL-Konventionen // PL/pgSQL-Prozeduren, die man in zwei Jahren noch lesen kann

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

Datenqualität in SQL Server // TRY_CONVERT für date, datetime, datetime2 und time sicher anwenden

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