Nachdem ich ein paar Artikel hier und da gelesen habe, habe ich festgestellt, dass die Kontrolle der Datenbankversion in einem Entwicklerteam von großer Bedeutung ist.
Bis jetzt habe ich jedes Mal ein einfaches dump whole database verwendet, wenn ein Update durchgeführt wurde. Wenn nur 1 Tabelle geändert wurde, können wir es schaffen, einfach die einzelne Tabelle zu löschen und dann erneut zu importieren. Nicht das beste, aber es funktioniert ganz gut, für additive Veränderungen und wir hatten noch keine Schluckauf.
Jetzt speichere ich eine .mwb (Mysql Workbench diagram) -Datei im Git-Repository des Projekts, an dem ich gerade arbeite.
Dann benutze ich auch dbv für schema management , zusammen mit git, wobei jede Verzweigung basierend auf dem Projekt benannt wird und es funktioniert ziemlich gut. Dadurch kann ich schematische Änderungen mit der Möglichkeit zum Zurücksetzen oder Zurücksetzen versionieren.
Was ist jedoch mit den Daten in den Tabellen? Wie kann dies aufrechterhalten werden? Vielleicht bin ich besser dran, nur mit der alten Methode zu bleiben. Ich verstehe Projekte mit der gleichen DB-Struktur, aber verschiedene Daten, die in Ordnung sind, aber was ist mit Websites mit bestimmten Datenbankdaten, die versioniert und verwaltet werden müssen.
Was ist mit der Basis bereits bereitgestellter Sites, die Datenbankänderungen benötigen, wie kann dies nahtlos sein? Einige haben vorgeschlagen, update / alter-Skripte zu verwenden, und das funktioniert gut mit Standardwerten und ähnlichem. Aber was, wenn ich eine Änderung an einer Website-Plattform vorgenommen habe, bei der jede Website-Datenbank geändert werden muss und die Daten intakt bleiben müssen?
Ich habe hauptsächlich im Bereich Business Application Development und Konfigurationsmanagement gearbeitet. Ihre Frage ist repräsentativ für die Herausforderungen in einer solchen Umgebung; Wenn Sie beispielsweise Microsoft Word aktualisieren, müssen Sie nicht alle Dokumente direkt von doc nach docx ändern. Und die Dokumente haben sogar eine einfachere Struktur als eine vollständige Beziehungsdatenbank.
Nicht so für Geschäftsanwendungen; Benutzer überspringen Releases, nehmen unerlaubte Änderungen am Datenmodell vor und das System muss weiter laufen und die richtigen Zahlen bereitstellen ...
Wir verwenden für unsere eigenen Anwendungen (das größte ist wie 600 Tabellen) ein selbst entwickeltes CASE-Tool, das Verzweigungen / Zusammenführungen enthält, aber der Ansatz kann auch manuell durchgeführt werden.
Das Datenmodell kann strukturiert aufgeschrieben werden. Zum Beispiel als Tabelleninhalt (CSV, um in eine Tabelle mit Metadaten geladen zu werden) oder als Code, der die verwendete Version erkennt und Spalten und Tabellen hinzufügt, wenn sie fehlen, einschließlich nicht-trivialer Migrationen.
Dies ermöglicht sogar mehreren Benutzern gleichzeitig, das Datenmodell zu ändern.
Wenn Sie die automatische Erkennung verwenden (z. B. verwenden wir einen Aufruf namens "verify_column" anstelle von "add_column"), ermöglicht dies sogar eine reibungslose Migration unabhängig von der Versionsnummer, von der der Kunde das Upgrade startet. Eine solche Prozedur analysiert die zu ändernde Tabelle und gibt die korrekte DDL aus, z. B. alter table t1 add col1 number not null , wenn eine Spalte fehlt, oder alter table t1 modify col1 not null , wenn die Spalte bereits vorhanden, aber nullfähig war.
Für Oracle und SQL Server kann ich Ihnen einige Beispielprozeduren zur Verfügung stellen. In MySQL würde ich dies mit einer Client-seitigen Sprache kodieren, vorzugsweise vom Betriebssystem unabhängig, damit Installationen unter Windows und Linux ausgeführt werden können. Vielleicht mit Apache Ant, wenn Sie damit Erfahrung haben.
Wir teilen die Tabellen in vier Kategorien ein:
Der Inhalt von Tabellen der Kategorie 'S' (gesetzte Daten) wird unter Versionskontrolle gesetzt. Normalerweise registrieren wir diese als Metadaten in unserem Fall-Tool, dann "Datensätze" genannt, aber Sie können auch zum Beispiel Microsoft Excel oder sogar Code verwenden.
In Excel hätten Sie beispielsweise eine Liste mit Zeilen mit gesetzten Daten. In Spalte A können Sie eine Excel-Funktion wie =B..&"|"&C..& "|" & ... eingeben, die alles verkettet und zum Laden mit einem Loader-Tool geeignet macht.
Zum Beispiel könnten Sie im Code einen Anruf haben wie:
%Vor%Das Excel ist ein wenig schwierig unter die Versionskontrolle zu bringen, so dass mehrere Benutzer den Inhalt gleichzeitig ändern können. Der Ansatz mit Code ist sehr einfach.
Denken Sie daran, Funktionen hinzuzufügen, um veraltete Daten zu entfernen. Zum Beispiel durch explizites Auflisten veralteter, gesetzter Daten oder durch automatisches Entfernen aller gesetzten Daten in den Tabellen, die von der letzten Installation nicht berührt wurden.
Sie müssen ein Transaktionsjournal für Ihr Datamodell erstellen, das mit Ihren Codeversionen synchronisiert ist. Für jedes Update, das Informationen hinzufügt (d. H. Ein neues Feld), können Sie einfach die Anweisungen wie 'ALTER TABLE x ADD COLUMN y ...' eingeben und einen DEFAULT VALUE (mit einer Funktion vielleicht) in einem Update-Skript angeben. Und eine "ALTER TABLE x REMOVE COLUMN y ..." für das Downdate-Skript. Sie müssen Ihre Daten exportieren, bevor Sie Informationen in einer Tabelle abschneiden. Sie können die gedumpten Tabellendaten für die inverse Transaktion in SQL konvertieren, sodass Sie die fehlenden Informationen mithilfe dieser Daten hinzufügen können.
Sie können eine "Journal" -Tabelle in Ihrem Datenmodell verwenden, um diese Transaktionen mit einfachen Ordnungszahlen zu verfolgen, die die verwendeten Skripts kennzeichnen. Wann immer die Software installiert ist, kann sie diese Zahlen vergleichen, um eine Liste von Transaktionen zu erstellen, die abgespielt werden müssen, um die Datenbank von Zustand N nach Zustand X zu bewegen, ohne Daten zu verlieren!
Tags und Links sql mysql database git database-versioning