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