Datenmigration: SQL Server nach PostgreSQL — der vollständige Leitfaden

von

Eine Datenmigration von SQL Server nach PostgreSQL scheitert selten am eigentlichen Kopieren der Daten. Sie scheitert an den stillen Unterschieden, die erst im Ziel auffallen: datetime, das keine Zeitzone kennt, bit, das kein boolean ist, ein IDENTITY, das zur Sequenz wird, und eine Collation, die plötzlich case-sensitiv vergleicht. Wer SQL Server nach PostgreSQL migrieren will, kopiert nicht einfach Tabellen — er übersetzt Typen, Schema, … Weiterlesen

Migration verifizieren — Datenqualität und Zeilen-Abgleich nach dem Umzug

von

Die Zeilenzahlen stimmen — Tabelle für Tabelle, Quelle gegen Ziel, alles grün. Und trotzdem ist die Migration nicht fertig. In einer Spalte sind aus NULL-Werten leere Strings geworden, in einer anderen hat der Umweg über eine CSV-Datei die letzte Nachkommastelle eines Betrags gerundet, und ein paar Umlaute sind zu Fragezeichen zerfallen. Gleiche Anzahl ist nicht gleiche Daten — … Weiterlesen

T-SQL nach PL/pgSQL portieren — Prozeduren und Funktionen migrieren

von

Die Daten sind drüben, das Schema steht — und dann liegen da 200 Stored Procedures, die kein Werkzeug für dich übersetzt. pgloader migriert Tabellen und Daten, aber die Logik in Prozeduren, Funktionen und Triggern bleibt liegen. Das ist die Phase, die wirklich Arbeit macht: T-SQL nach PL/pgSQL portieren, Zeile für Zeile, mit Verständnis statt Suchen-und-Ersetzen. Die gute Nachricht: Der … Weiterlesen

Daten transferieren: bcp, COPY, pgloader, ETL — welche Methode wann

von

Daten umziehen klingt nach der einfachsten Phase der Migration: Die Tabelle steht, die Daten rein, fertig. Bis die erste größere Tabelle einen ganzen Nachmittag braucht — weil sie Zeile für Zeile per INSERT läuft statt in einem Rutsch per COPY. Wer Daten nach PostgreSQL migrieren will, hat vier Wege zur Auswahl, und die Methodenwahl entscheidet über Stunden statt Minuten. Anders … Weiterlesen

Schema-Migration SQL Server → PostgreSQL — Identity, Constraints, Defaults, Sequenzen

von

Eine Schema-Migration SQL Server → PostgreSQL wirkt erledigt, sobald das CREATE TABLE-Skript ohne Fehler durchläuft. Genau dann beginnt das eigentliche Problem: Die Tabelle steht, die Daten sind drin — und der erste INSERT, der eine neue ID vergeben soll, kollidiert mit einem bestehenden Schlüssel. Der Grund ist kein Tippfehler, sondern ein Mechanismus-Wechsel. Aus IDENTITY wird in PostgreSQL eine Sequenz, und die … Weiterlesen

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

von

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

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

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

von

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