Was sind die besten Praktiken für Datenbank-Skripte unter Code-Kontrolle?

Question

Wir überprüfen derzeit, wie wir unsere Datenbankskripte (Tabellen, Procs, Funktionen, Ansichten, Datenkorrekturen) in Subversion speichern, und ich frage mich, ob es einen Konsens darüber gibt, was der beste Ansatz ist?

Einige der Faktoren, die wir berücksichtigen müssen, sind:

• Sollten wir Skripte "Erstellen" einchecken oder inkrementelle Änderungen mit Skripten "Ändern" einchecken?
• Wie können wir den Stand der Datenbank für eine bestimmte Version im Auge behalten?
• Es sollte einfach sein, eine Datenbank von Grund auf für jede beliebige Release-Version zu erstellen.
• Sollte es in der Datenbank eine Tabelle geben, in der die Skripte aufgelistet sind, die gegen sie gelaufen sind, oder die Version der Datenbank usw.

Das ist natürlich eine ziemlich offene Frage, deshalb bin ich gespannt, was die Leute aus ihren Erfahrungen gelernt haben.

Answer 1

Nach einigen Wiederholungen sah unser Ansatz ungefähr so aus:

Eine Datei pro Tabelle und pro gespeicherte Prozedur. Außerdem separate Dateien für andere Dinge wie die Einrichtung von Datenbankbenutzern und das Auffüllen von Nachschlagetabellen mit ihren Daten.

Die Datei für eine Tabelle beginnt mit dem Befehl CREATE und einer Reihe von ALTER-Befehlen, die im Laufe der Entwicklung des Schemas hinzugefügt werden. Jeder dieser Befehle ist in Klammern gesetzt, um zu prüfen, ob die Tabelle oder Spalte bereits existiert. Das bedeutet, dass jedes Skript in einer aktuellen Datenbank ausgeführt werden kann und nichts verändert. Es bedeutet auch, dass das Skript jede alte Datenbank auf das neueste Schema aktualisiert. Und bei einer leeren Datenbank erstellt das CREATE-Skript die Tabelle und die ALTER-Skripte werden alle übersprungen.

Wir haben auch ein Programm (in Python geschrieben), das das Verzeichnis mit den Skripten durchsucht und sie zu einem großen Skript zusammenfügt. Es analysiert die SQL-Skripte gerade so weit, dass es Abhängigkeiten zwischen den Tabellen ableitet (auf der Grundlage von Verweisen auf Fremdschlüssel) und sie entsprechend anordnet. Das Ergebnis ist ein riesiges SQL-Skript, das die Datenbank in einem Rutsch auf Vordermann bringt. Das Programm, das die Skripte zusammenstellt, berechnet auch den MD5-Hash der Eingabedateien und verwendet diesen, um eine Versionsnummer zu aktualisieren, die in eine spezielle Tabelle im letzten Skript der Liste geschrieben wird.

Das Ergebnis ist, dass das Datenbankskript für eine bestimmte Version des Quellcodes das Schema erstellt, mit dem dieser Code interagieren soll. Es bedeutet auch, dass es ein einziges (etwas umfangreiches) SQL-Skript gibt, das dem Kunden zur Verfügung gestellt wird, um neue Datenbanken zu erstellen oder bestehende Datenbanken zu aktualisieren. (Dies war in diesem Fall wichtig, weil es viele Instanzen der Datenbank geben würde, eine für jeden ihrer Kunden).

Answer 2

Unter diesem Link finden Sie einen interessanten Artikel: https://blog.codinghorror.com/get-your-database-under-version-control/

Sie befürwortet ein grundlegendes "create"-Skript, gefolgt von eincheckenden "alter"-Skripten und dem Führen einer Versionstabelle in der Datenbank.

Answer 3

Sie können einige Hinweise erhalten, indem Sie lesen, wie dies mit Ruby On Rails' Migrationen . Der beste Weg, dies zu verstehen, ist wahrscheinlich, es selbst auszuprobieren und dann die Datenbank manuell zu überprüfen.

Antworten auf jeden Ihrer Faktoren:

• Speichern Sie CREATE-Skripte. Wenn Sie die Version x.y.z auschecken wollen, wäre es schön, wenn Sie einfach Ihr Create-Skript ausführen könnten, um die Datenbank sofort einzurichten. Sie könnte fügen Sie auch ALTER-Skripte hinzu, um von der vorherigen Version zur nächsten zu gelangen (z. B. Sie übertragen Version 3, die ein CREATE-Skript der Version 3 und ein alter-Skript der Version 2 → 3 enthält).
• Siehe die Rails-Migrationslösung. Im Grunde behalten sie die Versionsnummer der Tabelle in der Datenbank, so dass Sie immer wissen.
• Verwenden Sie CREATE-Skripte.
• Die Verwendung von Versionsnummern wäre wahrscheinlich die allgemeinste Lösung - Skriptnamen und Pfade können sich im Laufe der Zeit ändern.

Meine zwei Cent!

Answer 4

Die Option Upgrade-Skript

Speichern Sie jede Änderung in der Datenbank als separates Sql-Skript. Speichern Sie jede Gruppe von Änderungen in einem nummerierten Ordner. Verwenden Sie ein Skript, um die Änderungen ordnerweise anzuwenden und in der Datenbank aufzuzeichnen, welche Ordner angewendet wurden.

Vorteile: Vollständig automatisierter, testbarer Upgrade-Pfad

Nachteile: Es ist schwierig, den vollständigen Verlauf jedes einzelnen Elements zu sehen. Man muss eine neue Datenbank von Grund auf neu erstellen und alle Versionen durchgehen

Answer 5

Ich neige dazu, dies im ersten Erstellungsskript zu überprüfen. Ich habe dann eine DbVersion-Tabelle in meiner Datenbank, und mein Code verwendet diese, um die Datenbank bei der ersten Verbindung zu aktualisieren, falls erforderlich. Wenn meine Datenbank beispielsweise die Version 1 hat und mein Code die Version 3, wendet mein Code die ALTER-Anweisungen an, um sie auf Version 2 und dann auf Version 3 zu bringen. Ich verwende dazu eine einfache Fallthrough-Switch-Anweisung.

Dies hat den Vorteil, dass bei der Bereitstellung einer neuen Version Ihrer Anwendung alte Datenbanken automatisch aktualisiert werden und Sie sich keine Sorgen machen müssen, dass die Datenbank nicht mehr mit der Software synchronisiert ist. Außerdem wird ein sehr übersichtlicher Änderungsverlauf geführt.

Dies ist nicht für jede Software eine gute Idee, aber es können Variationen angewendet werden.