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

von

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

von

Dieser Artikel destilliert eine erprobte Sammlung von PL/pgSQL-Konventionen aus einem produktiven ETL-Generator-Projekt: ein Namens-Standard mit Präfixen, eine zusammenklappbare Block-Body-Struktur, das Prinzip „Argumente als Variablen statt Inline-Werte“ und das tabellarische Alignment, das grep und Code-Review erst effizient macht. Das nimmst du mit: Voraussetzung: PostgreSQL 12+, Grundkenntnisse PL/pgSQL (CREATE PROCEDURE/FUNCTION, DECLARE, EXCEPTION-Handler). Inhalt Warum PL/pgSQL-Konventionen? Eine einzelne Stored Procedure ist immer lesbar … Weiterlesen

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

von

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 in SQL Server // TRY_CONVERT für bit sicher anwenden — Ja/Nein-Werte konvertieren

von

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 in SQL Server // TRY_CONVERT für float und real sicher anwenden

von

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

Datenqualität in SQL Server // TRY_CONVERT für money und smallmoney sicher anwenden

von

Wer einmal einen Kassen-Report mit Werten wie ‚1.234,56 €‘ aus einer CSV in eine SQL-Server-Datenbank importieren musste, kennt das Muster: TRY_CONVERT(money, ‚1,234.56‘) liefert 1234.5600. Doch TRY_CONVERT(money, ‚1.234,56‘) liefert NULL. Und selbst wenn der Import sauber läuft: money / 100 * 100 ist nicht zwangsläufig dasselbe wie der Ausgangswert. Kurzüberblick — was dieser Artikel klärt: Voraussetzung: SQL Server 2017+ (für TRIM im sicheren Pattern; vor 2017 als LTRIM(RTRIM(…))-Fallback). Kein Sample-Datensatz nötig … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für decimal und numeric sicher anwenden

von

Wer einmal einen Preis-Import gesehen hat, der aus ‚123,45 €‘ ein NULL macht statt der erwarteten Dezimalzahl, weiß: TRY_CONVERT(decimal(5, 2), ‚123,45‘) liefert NULL, weil das Komma als Dezimaltrennzeichen nicht erlaubt ist. Und selbst wenn das Komma weg ist: TRY_CONVERT(decimal(5, 2), ‚1234.56‘) ist auch NULL — diesmal wegen einer Vorkomma-Stelle zu viel. Auf einen Blick: Voraussetzung: SQL Server 2017+ (TRIM im sicheren Pattern; vor 2017 LTRIM(RTRIM(…))-Fallback). Postgres 12+ für … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für bigint, int, smallint und tinyint sicher anwenden

von

Datenqualität beginnt bei der Typ-Konvertierung — und bei Integer-Spalten zeigt TRY_CONVERT ein paar Eigenheiten, die im Import-Pfad gerne übersehen werden: eine leere Zeichenfolge wird zu 0 (statt zu NULL), jedes Dezimal- oder Tausendertrennzeichen führt zu einem NULL, und eine typisierte Dezimalzahl wird stillschweigend abgeschnitten — ohne Rundung. Dieser Artikel sortiert die Regeln, zeigt das sichere Konvertierungs-Pattern und reicht eine Postgres-Brücke nach. Kurzüberblick: … Weiterlesen

Datenqualität in einem ETL-Prozess — technische und fachliche Fehler erkennen, bevor sie das Zielsystem erreichen

von

Ein einziger nicht konvertierbarer Wert — ein Datum im falschen Format, eine Zahl mit dem falschen Dezimaltrennzeichen — und der ganze ETL-Lauf bricht ab. Datenqualität in einem ETL-Prozess heißt: solche Fehler proaktiv erkennen, protokollieren und isolieren, bevor sie das Zielsystem erreichen. Dieser Artikel ist der Einstieg in eine Serie, die genau das als Design Pattern umsetzt. TL;DR — … Weiterlesen

Design Pattern // Architektur eines ETL-Prozesses — wie sich schlechte Daten sauber isolieren lassen

von

Ein einziger nicht konvertierbarer Datums-Text, und der ganze ETL-Lauf bricht ab. Das hier vorgestellte Design Pattern für die Architektur eines ETL-Prozesses verhindert genau das: schlechte Daten werden isoliert, nicht weitergereicht. TL;DR — was dieser Artikel zeigt: Voraussetzung. Grundverständnis von ETL-Prozessen. Konzeptueller Artikel — kein Schritt-für-Schritt-Tutorial. Wurzel der Artikelserie: Datenqualität in einem ETL-Prozess; der vorliegende Artikel ist der Architektur-Teil. … Weiterlesen