PostgreSQL

Warum sqlfluff unsere SQL-Konventionen nicht prüfen kann — ein eigener Guard in 240 Zeilen

von

Die Konventionen standen fest: Prozedur-Skelette, DECLARE-Banner, Datei-Naming, verbotene Konstrukte — alles versioniert in Regel-Dateien, jede Regel mit Begründung. Offen war nur noch die Frage, mit welchem Werkzeug sich die SQL-Konventionen prüfen lassen. Und der erste Reflex hieß, wie vermutlich in jedem Postgres-Team mit Konventions-Ambition: „Nimm doch sqlfluff, das ist doch genau dafür da.“ Drei reale … Weiterlesen

Drei Schweregrade statt pass/fail — und warum der Schweregrad entscheidet, wo die Regel steht

von

Die meisten Datenqualitäts-Systeme sterben nicht an schlechten Prüfungen, sondern an einem fehlenden Feld im Regel-Modell: dem Schweregrad. Ein fehlendes Länderkürzel in drei von 80.000 Zeilen blockiert den Nacht-Load, jemand schaltet die Prüfung „vorübergehend“ ab, und ab da läuft alles ungeprüft. Wer Datenqualität mit Schweregraden statt mit binärem pass/fail steuert, entkommt dieser Falle. Und der Schweregrad kann noch … Weiterlesen

Prüfregeln aus dem Schema ableiten — was die Metadaten schon wissen

von

Die Regel „country_code ist Pflicht“ steht zweimal in der Datenbank: einmal als NOT NULL im Schema der Zieltabelle, einmal als handgetippte Zeile in der Prüf-Konfiguration. Beim nächsten ALTER TABLE ändert sich nur eine der beiden Stellen, und die Prüfung wird still falsch. Wer Prüfregeln ableiten kann, statt sie zu tippen, muss diese Wiederholung nicht mehr pflegen: Die Metadaten wissen längst, welche Spalten … Weiterlesen

SQL Server vs. PostgreSQL — Vor- und Nachteile für den Umstieg

von

SQL Server oder PostgreSQL — die Frage ist selten „Welche Datenbank ist besser?“, sondern „Welche passt zu Budget, Team und Plattform?“. Wer die beiden Fragen verwechselt, migriert aus den falschen Gründen und merkt es erst, wenn die Lizenzrechnung zwar schrumpft, die Betriebskosten aber wachsen. Kurzüberblick: Voraussetzung: SQL-Server-Praxiserfahrung genügt. PostgreSQL-Begriffe wie MVCC oder Extensions werden beim ersten … Weiterlesen

Ein Claude-Code-Projekt mit Entwicklungsworkflow und Datenbank aufsetzen — das offene Starter-Kit im Überblick

von

Ein leeres Repo und Claude Code, Anthropics Coding-Agent im Terminal — mehr braucht es nicht, um loszulegen. Und genau das ist das Problem: Das Modell schreibt sofort Code, aber von Haus aus sorgt nichts dafür, dass vorher eine Spezifikation entsteht, hinterher ein Review stattfindet oder das Datenbank-Schema reproduzierbar deployt wird. Wer ein Claude-Code-Projekt aufsetzt, entscheidet … Weiterlesen

Datenbank-CI/CD mit PostgreSQL — der komplette Lebenszyklus vom Objekt-File bis zum automatischen Deploy

von

In vielen Projekten lebt das Datenbank-Schema in der Datenbank statt im Repository — gewachsen aus Jahren von Hand-ALTERs, vollständig dokumentiert nirgends. Auffallen tut das erst, wenn eine zweite Umgebung entstehen soll oder ein Deploy zerbricht. Datenbank-CI/CD dreht das Verhältnis um: Das Repository beschreibt den Soll-Zustand, und jede Umgebung — von der Wegwerf-Datenbank im CI bis zur Produktion … Weiterlesen

GitHub Actions für Postgres-Deploys — mit Wegwerf-Datenbank als Qualitäts-Gate

von

Der Fehler war ein Tippfehler in einem ALTER TABLE — gefunden hat ihn der Staging-Deploy am Freitagnachmittag. Dabei ist genau dieser Fund automatisierbar: Wer den Postgres-Deploy über GitHub Actions gegen eine Wegwerf-Datenbank fährt, macht aus jedem Pull Request einen vollständigen Probelauf. Syntax- und Semantik-Fehler, Reihenfolge-Probleme und kaputte Idempotenz fallen dann vor dem Merge auf — nicht auf Staging. Das … Weiterlesen

Schema-Änderungen tracken ohne Framework — Run-once-Skripte, Checksummen und Immutabilität

von

Der Backfill lief beim zweiten Deploy noch einmal — und hat Werte überschrieben, die in der Zwischenzeit fachlich korrigiert worden waren. Solche Unfälle verhindert keine Disziplin, sondern nur ein Gedächtnis: Wer Schema-Änderungen tracken will, ohne gleich Flyway oder Liquibase einzuführen, braucht dafür genau eine Tabelle und rund 40 Zeilen Shell — und trifft dabei dieselben vier Design-Entscheidungen, … Weiterlesen

NOT-NULL-Spalte nachträglich hinzufügen — das Expand/Contract-Muster für befüllte Tabellen

von

Lokal lief der ALTER TABLE sauber durch — auf Staging bricht derselbe Deploy mit column „country_code“ of relation „customer“ contains null values. Der Unterschied ist nicht das SQL, sondern die Daten: Die lokale Tabelle war leer, die auf Staging nicht. Wer eine NOT-NULL-Spalte nachträglich zu einer befüllten Tabelle hinzufügen will, braucht mehr als ein Statement — er braucht die richtige … Weiterlesen

SQL-Schema deployen ohne Migrations-Tool — Verzeichnis-Konvention statt Flyway oder Liquibase

von

Das Schema steht — und jetzt? Der Reflex heißt Flyway oder Liquibase. Aber ein Migrations-Tool ist für ein kleines, datenbank-zentriertes Projekt oft mehr Apparat, als die Aufgabe verlangt: eine eigene Versions-Tabelle, eine Runtime-Abhängigkeit, ein Format, an das man sich bindet. Es geht auch anders. Ein SQL-Schema deployen ohne Migrations-Tool heißt: ein paar Konventionen, idempotente Skripte und ein … Weiterlesen