Schema-Migration: SQL Server-Datentools gegen Liquibase und Flyway

Dies mag wie eine dumme Frage erscheinen, aber ich habe nach Open-Source-Lösungen für die Schemamigration gesucht, nämlich Liquibase und Flyway.

Mein Chef sagte mir jedoch, dass SQL Server Data Tools (SSDT) ​​den gleichen Job erledigt. Ich bin mir nicht sicher, ob ich damit einverstanden bin, aber ich kann im Internet nur sehr wenig finden, das es direkt mit Liquibase und / oder Flyway vergleicht.

Meiner Ansicht nach ist SSDT ein Entwicklungs-, Datenmodellierungs- und Designtool für SQL Server und unterstützt auch den Schemavergleich (und das Generieren von Skripten davon) und die Quellcodeverwaltung. Es befasst sich mit einem anderen Problem, obwohl es in einigen Aspekten der Schemamigration zu Überschneidungen mit Liquibase / Flyway kommen kann. Als allgemeines Schema-Migrationswerkzeug sind Liquibase und Flyway jedoch vollständig dedizierte Werkzeuge, während SSDT eher für den Entwurf und die Entwicklung einer Datenbank bestimmt ist.

Alle Meinungen wären sehr dankbar, auch wenn nur gesagt wird, dass es keinen Vergleich gibt und SSDT per se überhaupt kein Schema-Migrations-Tool ist.

SSDT ist vergleichbar mit Liquibase / Flyway, da es das tut, was sie tun, aber einen anderen Ansatz verfolgt. Mit SSDT verfügen Sie über die Entwicklungsumgebung, sodass Sie beispielsweise zur Definition gehen, Referenzen und Intelligenz finden sowie ein Projekt in einen Dacpac kompilieren und diesen Dacpac dann in einer Datenbank bereitstellen können.

Die SSDT-Methode (und die Redgate-SQL-Vergleichsmethode) für eine Deloyment besteht darin, zu deklarieren, was Sie möchten, wenn Sie eine Tabelle ändern möchten, die wie folgt aussieht:

create table a(id int)

zu einem Tisch, der aussieht wie:

create table a(id int, another_column varchar(12))

Mit SSDT ändern Sie einfach Ihre Tabellendefinition in die zweite und lassen SSDT sich Gedanken über das Upgrade machen (kann es eine Tabelle ändern, eine Spalte hinzufügen oder die Spaltenreihenfolge ändern, sodass Sie die Tabelle neu erstellen müssen usw.).

Bei Liquibase (DbUp, ReadyRoll, manuelle Methoden usw.) müssen Sie in diesem Fall die Änderungstabelle selbst schreiben und sicherstellen, dass Sie die Skripte in der richtigen Reihenfolge ausführen. Betrachten Sie dieses Szenario:

1. Release 1 - Spalte Hallo auf Tabelle erstellen
2. Release 2 - benenne die Spalte Hallo in joe_blogs um
3. Release 3 - benenne die Spalte joe_blogs in hallo um
4. Release 4 - Spalte joe_blogs erstellen

Wenn eine der Veröffentlichungen übersehen wird, kann keine der nächsten fortgesetzt werden.

Vorteile von Upgrade-Skripten (Liquibase, DbUp usw.):

• Sie haben die vollständige Kontrolle über die Skripte
• DBAs / Entwickler sind daran gewöhnt

Vorteile von Vergleichen / Zusammenführen (SSDT, Redgate SQL Compare):

• Sie müssen keine Upgrade-Skripte schreiben
• Es ist einfach, zu einer bestimmten Version zu gelangen, indem Sie diese Version vergleichen und zusammenführen

Nachteile von Upgrade-Skripten:

• Muss in der richtigen Reihenfolge ausgeführt werden
• Verlassen Sie sich auf Menschen, die keine Fehler machen
• Kann langsam sein, besonders wenn Sie viele Änderungen haben
• Es sei denn, Ihr Team ist sehr diszipliniert. Datenbanken in verschiedenen Umgebungen (Entwickler, Test, Staging, Produkt usw.) sind häufig nicht mehr synchron und machen Tests ungültig
• Ein Downgrade einer Version bedeutet, dass Sie die Rückseite aller bereits geschriebenen Skripte schreiben

Nachteile der Verwendung von Vergleichen / Zusammenführen:

• Tools sind nicht 100% vertrauenswürdig, vielleicht zu Unrecht
• SSDT erfordert ein funktionierendes Projekt, viele, viele Datenbanken haben Code, der nicht kompiliert oder ausgeführt wird (denken Sie an abgelegte Tabellen, aber keine Prozeduren usw.). Ich habe dies in ungefähr 8/10 Datenbanken gesehen, die ich geerbt habe :)
• Viele Datenbankadministratoren / Entwickler zögern, die Entwicklung in SSMS / Notepad aufzugeben

Persönlich denke ich wirklich, dass SSDT eine professionelle Entwicklungsumgebung ist und dass ich mich darauf konzentrieren kann, nützlichen Code und Tests zu schreiben, anstatt Upgrade-Skripte zu schreiben, die an sich nur ein Mittel zum Zweck sind.

Du hast nach Meinungen gefragt, also los geht's :)

ed

Ich habe nur die Antwort auf die Voraussage aufgefüllt.

Der größte Unterschied, der auf der Flyway-Website an zentraler Stelle beschrieben wird:

Löst nur ein Problem und löst es gut. Flyway migriert Ihre Datenbank, sodass Sie sich keine Sorgen mehr machen müssen.

Visual Studio + SSDT + SSIS = ETL-Tool mit voller Leistung, mit nur einem wirklichen Nachteil - es funktioniert nur unter Windows Es benötigt Windows + SQL Server zum Ausführen von Paketen, funktioniert jedoch mit fast allen Quellen.

Für die Übertragung / Migration von Daten - viele Produkte auf dem Markt. Kommerziell, Open Sources, Community / Express und etc.

Für Code migrieren - alles nicht so gut. Selbst wenn die Software verspricht, "Trigger, Prozeduren und Funktionen ohne Probleme zu konvertieren", ist dies in der Tat nur ein einfaches Handbuch für die meisten Codemigrationen.

Ich habe sowohl mit SQL Server-Datentools als auch mit Flyway gearbeitet. Mit SSDT habe ich folgende Vorteile:

1. Ich kann das Datenbankprojekt kompilieren. Das heißt, es besteht keine Angst, eine Spalte zu löschen, auf die von einer Ansicht, Funktion oder gespeicherten Prozessen verwiesen wird. Dies ist eine großartige Funktion, da wir in der Vergangenheit erst nach der Veröffentlichung solche Fehler festgestellt haben

2. Nach erfolgreicher Erstellung generiert SSDT einen sogenannten "DACPAC". Stellen Sie sich das als MSI mit einer Version vor.

3. Ein gegebener Dacpac, beispielsweise Version 5, kann auf eine Datenbank angewendet werden, die auf Dacpac Version 1,2,3,4 oder 6,7,8 usw. basiert. Wenn er auf 1-4 angewendet wird, wird die Datenbank aktualisiert. Bei Anwendung auf 6,7 usw. wird die Datenbank heruntergestuft / zurückgesetzt. Bei Datenverlust werden Warnungen ausgegeben, die unterdrückt werden können. Wir erhalten also eine großartige Rollback-Funktion, die mit anderen Tools wie Flyway usw. nicht verfügbar ist. Mit Flyway muss ein neuer Satz von Skripten für das Rollback bereitgestellt werden.

4. DACPAC wendet alle Änderungen in einer Transaktion an. Das heißt, wenn das Upgrade 5 Tabellenänderungen enthält und eine davon fehlschlägt, wird die gesamte Transaktion zurückgesetzt. Flyway unterstützt dies ebenfalls, jedoch für jede Datei.

SSDT und DACPACs sind jedoch Microsoft SQL Server-spezifisch. flyway kann für eine Vielzahl von Datenbanken verwendet werden.

Wenn Sie also nur SQL Server verwenden, sollte es eine ziemlich einfache Entscheidung sein, sich für SSDT und DACPACs zu entscheiden.