Datenbank Version/Change Control für Daten nicht Schema?

Question

Nachdem ich ein paar Artikel hier und da gelesen habe, habe ich festgestellt, dass die Datenbankversionskontrolle in einem Entwicklungsteam tatsächlich von großer Bedeutung ist.

Bis jetzt habe ich eine einfache dump whole database jedes Mal verwendet, wenn es ein Update gibt, wenn nur 1 Tabelle geändert wurde, können wir manchmal mit dem Dumping der einzelnen Tabelle und dann Reimportation durchkommen. Nicht das beste, aber es funktioniert ganz gut, für additive Änderungen und wir hatten noch keine Schluckauf.

Jetzt speichere ich eine .mwb (Mysql Workbench diagram) Datei im Git-Repository des Projekts, an dem ich arbeite. Dann verwende ich auch dbv für schema management, zusammen mit git, wobei jeder Zweig auf der Grundlage des Projekts benannt wird und es funktioniert ziemlich gut. Dies ermöglicht es mir, schematische Änderungen mit der Möglichkeit zum Zurücksetzen oder Rollback zu versionieren.

Was ist jedoch mit den Daten in den Tabellen enthalten. 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.

Auch was die Basis der bereits bereitgestellten Websites, 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?

Answer 1

Ich habe hauptsächlich in der Entwicklung von Geschäftsanwendungen 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 einer vollständigen Beziehungsdatenbank.

Nicht so für Geschäftsanwendungen; Benutzer überspringen Releases, machen unerlaubte Änderungen am Datenmodell und das System muss weiter laufen und die richtigen Nummern bereitstellen ...

Wir verwenden für unsere eigenen Anwendungen (das größte ist wie 600 Tabellen) ein selbstentwickeltes CASE-Tool Dies umfasst die Verzweigung/Zusammenführung, aber der Ansatz kann auch manuell durchgeführt werden.

Versioning Datenmodell

Das Datenmodell kann nach unten in einer strukturierten Art und Weise geschrieben 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 nicht löschbar ist.

Für Oracle und SQL Server kann ich Ihnen ein paar 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.

Versioning Daten

Wir teilten die Tabellen in vier Kategorien:

• R: Referenzdaten; Daten, die die Anwendungssite bereitstellen muss, bevor er das System tatsächlich verwendet. Zum Beispiel Hauptbuchkontencodes. Die Referenzdaten ändern sich selten nach dem Produktivstart und wachsen nicht kontinuierlich. Die Inhalte spiegeln das Geschäftsmodell der Website wider, in dem die Anwendung verwendet wird.
• T: Transaktionsdaten; Daten, die die Website während der Nutzung der Anwendung registriert, ändert und entfernt. Zum Beispiel Hauptbucheinträge. Die Transaktionsdaten beginnen bei 0 und wachsen kontinuierlich. Wenn sich das Unternehmen verdoppelt, verdoppelt sich auch die Transaktionsmenge.
• S: gesetzte Daten; Daten, die NICHT vom Benutzer auf der Site gepflegt werden, aber von der sich entwickelnden Partei zur Verfügung gestellt und gepflegt werden. Im Wesentlichen wird Code in Daten umgewandelt. Zum Beispiel steht "F" für "Weiblich". Fehler in den gesetzten Daten können zu Systemfehlern führen.
• O: der Rest (im Idealfall nicht erforderlich, da sie technisch sind, aber einige Systeme benötigen einen temporären Tisch A oder einen Scratch-Tisch B).

Der Inhalt von Tabellen der Kategorie 'S' (gesetzte Daten) steht unter Versionskontrolle. 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.

Zum Beispiel, in Excel würden Sie eine Liste von Zeilen mit gesetzten Daten haben. 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 in Code, können Sie einen Anruf wie haben:

verifySeed('TABLE_A', 'CODE', 'VALUE') 

Das Excel ist ein wenig schwer unter Versionskontrolle zu bringen mehr Benutzer ermöglichen Inhalte in der gleichen Zeit zu ändern. Der Ansatz mit Code ist sehr einfach.

Denken Sie daran, Funktionen hinzuzufügen, um veraltete Daten zu entfernen. Zum Beispiel durch explizites Auflisten von veralteten, gesetzten Daten oder durch automatisches Entfernen aller gesetzten Daten, die in den Tabellen vorhanden sind, aber nicht von der letzten Installation berührt wurden.

Answer 2

Sie müssen ein Transaktionsjournal auf Ihrem Datamodel führen, 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 mithilfe einfacher Ordnungszahlen zu verfolgen, die die verwendeten Skripts kennzeichnen. Wenn die Software installiert wird, 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 Datenverlust!