Datenbank Change Management - Einrichtung für Initial erstellen Scripts, Nachträgliche Migration Scripts

Question

Ich habe ein Datenbank Change-Management-Workflow an Ort und Stelle bekommt. Es basiert auf SQL-Skripts (so, es ist keine verwalteten Code-basierte Lösung).

Die Grundeinstellung sieht wie folgt aus:

Initial/
    Generate Initial Schema.sql
    Generate Initial Required Data.sql
    Generate Initial Test Data.sql
Migration
     0001_MigrationScriptForChangeOne.sql
     0002_MigrationScriptForChangeTwo.sql
     ...

Der Prozess, eine Datenbank spin up ist dann alle Initlal Skripts ausführen und dann die sequenzielle Migration Skripts ausführen. Ein Werkzeug nimmt Fall der Versionierung Anforderungen usw.

Meine Frage ist, in dieser Art von Setup, ist es sinnvoll, dies auch zu halten:

Current/
    Stored Procedures/
        dbo.MyStoredProcedureCreateScript.sql
        ...
    Tables/
        dbo.MyTableCreateScript.sql
        ...
    ...

Mit dem „das“ ich ein Verzeichnis von Skripten bedeuten (nach Objekttyp getrennt), die die Skripte erstellen stellt für die Spinnerei bis die Strom / latest Version der Datenbank.

Aus irgendeinem Grund Ich mag die Idee, aber ich kann nicht konkret es die Notwendigkeit rechtfertigen. Bin ich etwas fehlt?

Die Vorteile wären:

• Für Entwickler und Quellcodeverwaltung, müssten wir das gleiche Objekt-pro-Datei-Setup, dass wir es gewohnt sind
• Für den Einsatz, können wir eine neue DB-Instanz auf die neueste Version entweder durch Ausführen des Initial + Migrate, oder indem Sie die Skripte von Current /
spin up
• Für Entwickler, wir brauchen keine DB-Instanz in fahrbereitem Zustand Entwicklung zu tun. Wir können auf dem Current / Ordner "offline" Entwicklung tun.

Die Nachteile wären:

• Für jede Änderung, müssen wir die Skripte in der Current / Ordner aktualisieren, sowie eine Migration Skript (in der Migration / Ordner) erstellen

Vielen Dank im Voraus für jede Eingabe!

Answer 1

Eigentlich ist dies der beste Weg. Wie umständlich, wie es klingen mag, ist es besser als die Alternativen von SQL mit Vergleichen wie Werkzeuge oder VSDB .schema Datei-Bereitstellung. Ich habe genau das smae Ansatz seit einiger Zeit argumentiert jetzt: Version Kontrolle und Ihre Datenbank . Meine Apps bereitstellen, das v1-Schema aus dem anfänglichen Skript, dann Upgrade-Skript für jede Version laufen. Jedes Skript Know-how von Version N-1 bis N aktualisieren, und nur das. Endergebnis ist die aktuelle Version.

Die größte ist zurückweichen Fehlen einer autoritativen SQL-Datei zu suchen, die Strom Version eines Objekts zu finden (Verfahren, Tabelle, Ansicht usw.). Aber die Vorteile der Lage, Ihre App über die Bereitstellung jeder vorherige Version, und der Vorteil der Bereitstellung von gut kontrolliert und getestet Skripte überwiegen bei weitem den Nachteil.

(. Skript v1 bereitstellen dann v1.1 anwenden, dann v1.2 ... bis schließlich Sie v4.5 gelten, Strom)

Wenn Sie das Deployment-Prozess fühlen sich schlecht für die Verwendung dann dies im Auge behalten: genau das gleiche Prozess wird von SQL Server intern aktualisieren die Datenbank zwischen den Versionen verwendet. Wenn Sie eine ältere Datenbank anhängen, sehen Sie die berühmte ‚Datenbank wird das Upgrade von Version 611-612 läuft‘ und Sie sehen, dass das Upgrade geht Schritt für Schritt , aktualisieren Sie nicht gerade auf die aktuelle Version 651 ( oder was auch immer ist in Ihrem Fall Strom). Auch nicht das Upgrade ein Diff-Tool läuft v 651 über v einzusetzen. 611. Das heißt, weil die am besten Ansatz ist, die Sie gerade verwenden, aktualisieren Sie Schritt für Schritt zu einem Zeitpunkt.

Und eine wirkliche Antwort auf Ihre Frage an, nach einer ziemlich schrägen rant Posting (Ist ein Thema, das ich über eine starke Meinung haben, können Sie sagen?): Ich denke, wertvoll ist eine Skriptversion der aktuellen Version zu haben, aber ich denke, es sollte eine zusammenhängende Integration Build-Prozess lieferbar sein. Mit anderen Worten, sollte Ihr Build-Server die aktuelle Datenbank (mit dem Upgrade-Skripte) und dann, als Build Schritt Skript aus der Datenbank und erzeugt einen Build Drop mit dem aktuellen Version Schema Skript bauen. Aber diejenigen, die nur als Referenz für die Suche und Code-Inspektion verwendet werden sollen, nicht als Einsatz lieferbar, mein 2C.

Answer 2

Ich denke, es wird nur auf lange Sicht die Dinge komplizierter machen. Ganze Versionen müssen in einem einzigen Skript leben, so dass Sie das Skript in einem Kontext testen und wissen, dass es in einem anderen Zusammenhang, wie die Produktion korrekt funktionieren.

Answer 3

Martin,

Wenn Sie in der realen Welt sind, dann Ihre Produktionsdatenbank akzeptiert nur Updates - Sie nie „schaffen“ es von Grund auf neu. Also das Wichtigste für Sie zu speichern, zu beobachten, Überprüfung usw. ist die Menge des Update-Skripte. Das sind die Skripte, die es zu Produktion machen wird, so dass diejenigen, die einzigen, die wirklich wichtig sind.

Sie sind das Richtige zu tun, indem sie primäre machen. Doch die Entwickler Bedürfnisse der Lage sein, ein „aktuelles Bild“ zu bekommen, was das Schema aussieht. DBAs mag, dies zu tun, auch, obwohl (zu) häufig sie es in den Produktionsserver durch die Protokollierung zu tun und eine Art von GUI-Tool Anheizen. (Igitt!)

Der einzige Vorbehalt, den ich über Ihren Ansatz habe, ist der Strom / vorherige Schema nach Objekttyp . Diese Skripte sollten automatisch generiert werden, von Dumping der Datenbank selbst. Wenn Sie können sie automatisch vom Typ kategorisieren, dann großartig! Wenn nicht, tun, was können Sie sie einfach zu bedienen zu machen, aber die Führungs Regel sollte immer „von einer Live-Datenbank automatisch generiert“ werden.