Fügen Sie altes und neues Schema ein und wählen Sie den Dialekt. Prüfen Sie das erzeugte SQL: Tabellen- und Spaltenlöschungen sind auskommentiert, alle übrigen Anweisungen sollten vor der Ausführung kontrolliert werden.
Läuft lokal in deinem BrowserFügen Sie das alte Schema unter Before und das neue unter After ein, wählen Sie PostgreSQL oder MySQL und klicken Sie auf Migration erzeugen. Das Werkzeug liest die CREATE-TABLE-Anweisungen und schreibt die ALTER- und CREATE-Anweisungen, die einen Snapshot in den anderen überführen.
Alles läuft im Browser; kein Schema-Text verlässt die Seite. Das Ergebnis ist ein Prüfentwurf: Anweisungen, die Daten zerstören können, stehen als Kommentar, damit nichts versehentlich ausgeführt wird.
Verglichen werden Tabellen und Spalten: hinzugefügte und entfernte Tabellen und Spalten, Typänderungen, NOT-NULL-Änderungen und Änderungen des Standardwerts. Auch Primärschlüssel werden gemeldet, wenn sie hinzukommen, entfallen oder andere Spalten umfassen, einschließlich Definitionen auf Tabellenebene wie PRIMARY KEY (a, b).
Fremdschlüssel werden verglichen, egal ob sie an der Spalte stehen (REFERENCES users(id)) oder als Tabellen-Constraint (FOREIGN KEY (a, b) REFERENCES parent (x, y)). Ein neuer Schlüssel wird zu ADD CONSTRAINT, ein entfernter bleibt mit dem erzeugten Constraint-Namen als Kommentar stehen.
DROP TABLE, DROP COLUMN sowie entfernte Primär- und Fremdschlüssel werden unter einem DESTRUCTIVE-Hinweis als Kommentar ausgegeben, weil sie Daten oder Constraints verwerfen, die ein erneuter Lauf nicht zurückholt. Diese Seite führt nichts aus; Sie entscheiden, welche Zeilen aktiv werden.
Gelesen werden nur CREATE-TABLE-Anweisungen. UNIQUE-, CHECK- und INDEX-Definitionen werden nicht verglichen, und Datenänderungen, Umbenennungen, Views, Sequences, Trigger, Rechte sowie herstellerspezifische Tabellenoptionen liegen außerhalb des Umfangs. Wurden solche Definitionen übersprungen, sagt der Entwurf das, statt einen sauberen Diff zu melden.
Testen Sie zuerst auf einer Staging-Kopie und erzeugen Sie das Schema mit einem reinen Schema-Dump, damit Daten den Diff nicht verdecken. PostgreSQL führt fast alles DDL in einer Transaktion aus, BEGIN und ROLLBACK können eine falsche Migration also zurücknehmen; MySQL bestätigt DDL implizit, dort muss ein Fehler nach vorn korrigiert werden.
NOT NULL oder ein Primärschlüssel zu ergänzen validiert oder schreibt eine bestehende Tabelle neu und kann dabei eine Sperre halten. Prüfen Sie die Dauer an der echten Tabellengröße (PostgreSQL validiert NOT NULL mit einem vollen Scan, MySQL baut die Tabelle möglicherweise neu auf) und planen Sie die Änderung, statt sie zur Spitzenzeit auszuführen.