SQL & Datenbanken

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

von

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

von

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

von

„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

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

von

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

von

Wer einmal eine CSV-Spalte mit gemischten Datums-Formaten in eine datetime-Spalte importieren musste, weiß: An der Typ-Konvertierung entscheidet sich, ob fehlerhafte Datumswerte auffallen oder unbemerkt in die Pipeline gelangen. SQL Server lässt einen mit style-Codes alleine, sobald das Format vom Standard abweicht — TRY_CONVERT deckt die dokumentierten style-Formate ab, für alles andere braucht es eine eigene Parsing-Strategie. Das nimmst du mit: Voraussetzung: SQL Server … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für bit sicher anwenden — Ja/Nein-Werte konvertieren

von

Wer einmal eine Ja/Nein-Spalte aus einem Legacy-Export übernommen hat, kennt den Befund: Die Quelle liefert ‚J‘, ‚ON‘ oder ein schlichtes ‚x‘, und TRY_CONVERT(bit, N’J‘) quittiert die deutsche Notation mit NULL. Eingebaut versteht SQL Server beim bit-Ziel nur Integer-Strings und die Literale ‚true’/’false‘ — jede andere Yes/No-Notation braucht eine eigene Zuordnung. Auf einen Blick: Voraussetzung: TRY_CONVERT existiert seit SQL Server 2012. Die Funktion fn_convert_bit nutzt TRIM und braucht daher SQL Server 2017+ … Weiterlesen

Datenqualität in SQL Server // TRY_CONVERT für float und real sicher anwenden

von

Wer einmal eine Messreihe importiert hat, in der jede leere Zelle als 0 in der Zieltabelle landete, kennt die Falle: TRY_CONVERT(float, “) liefert nicht NULL, sondern 0. Der Mittelwert über die Spalte ist danach falsch, und dem Ergebnis sieht man das nicht an. Auf einen Blick: Voraussetzung: TRY_CONVERT existiert seit SQL Server 2012. Das sichere Pattern weiter unten nutzt TRIM und braucht daher SQL Server … 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. Auf einen Blick: Voraussetzung: TRY_CONVERT gibt es seit SQL Server 2012. Das sichere Pattern verwendet zusätzlich TRIM und braucht damit SQL … 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 Vorkommastelle zu viel. Auf einen Blick: Voraussetzung: TRY_CONVERT existiert seit SQL Server 2012. Das sichere Pattern nutzt TRIM und braucht daher SQL … Weiterlesen

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

von

Ein CSV-Import läuft ohne Fehlermeldung durch, und hinterher steht in der Mengen-Spalte eine 0, wo das Quellfeld schlicht leer war: TRY_CONVERT(int, N“) liefert 0, nicht NULL. Die zweite Eigenheit betrifft bereits typisierte Dezimalzahlen: TRY_CONVERT(int, 1234.5) rundet nicht, sondern schneidet ab — das Ergebnis ist 1234, nicht 1235. Auf einen Blick: Voraussetzung: TRY_CONVERT gibt es seit SQL Server 2012. Das sichere Pattern verwendet zusätzlich TRIM und braucht damit SQL … Weiterlesen