Datenbankversion / Änderungskontrolle für Daten kein Schema?

Ich habe hauptsächlich in der Entwicklung von Geschäftsanwendungen und im Konfigurationsmanagement gearbeitet. Ihre Frage steht stellvertretend für die Herausforderungen in einem solchen Umfeld; Wenn Sie beispielsweise Microsoft Word aktualisieren, müssen Sie nicht alle Dokumente sofort von doc auf 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 nicht autorisierte Änderungen am Datenmodell vor und das System muss weiterlaufen und die richtigen Zahlen liefern ...

Wir verwenden für unsere eigenen Anwendungen (die größte hat ungefähr 600 Tabellen) ein selbst entwickeltes CASE-Tool, das Verzweigungen/Zusammenführungen enthält, aber der Ansatz kann auch manuell erfolgen.

Versionsdatenmodell

Das Datenmodell kann strukturiert niedergeschrieben werden. Zum Beispiel als Tabelleninhalt (CSV zum Laden in eine Tabelle mit Metadaten) oder als Code, der die verwendete Version erkennt und fehlende Spalten und Tabellen hinzufügt, einschließlich nicht-trivialer Migrationen.

So können sogar mehrere Benutzer gleichzeitig das Datenmodell ändern.

Wenn Sie die automatische Erkennung verwenden (wir verwenden beispielsweise 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 richtige DDL aus, wie 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 nullable war.

Für Oracle und SQL Server kann ich Ihnen einige Beispielprozeduren zur Verfügung stellen. In MySQL würde ich dies mit einer clientseitigen Sprache codieren, vorzugsweise betriebssystemunabhängig, damit Installationen unter Windows und Linux ausgeführt werden können. Vielleicht mit Apache Ant, wenn Sie damit Erfahrung haben.

Versionierung von Daten

Wir teilen die Tabellen in vier Kategorien ein:

• R:Bezugsdaten; Daten, die der Anwendungsstandort bereitstellen muss, bevor er das System tatsächlich nutzt. Zum Beispiel Hauptbuchkontocodes. Die Referenzdaten ändern sich nach dem Go-Live selten und werden nicht kontinuierlich größer. Die Inhalte spiegeln das Geschäftsmodell der Website wider, auf der 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 der Umsatz des Unternehmens verdoppelt, verdoppeln sich auch die Transaktionsdaten.
• S:Seeding-Daten; Daten, die NICHT vom Benutzer auf der Website gepflegt, sondern von der Entwicklungspartei bereitgestellt und gepflegt werden. Im Wesentlichen handelt es sich dabei um Code, der in Daten umgewandelt wird. „F“ steht beispielsweise für „weiblich“. Fehler in Seeding-Daten können zu Systemfehlern führen.
• O:der Rest (idealerweise nicht benötigt, da sie technisch sind, aber einige Systeme erfordern eine temporäre Tabelle A oder eine Scratch-Tabelle B).

Der Inhalt von Tabellen der Kategorie 'S' (seeded data) wird unter Versionskontrolle gestellt. Normalerweise registrieren wir diese als Metadaten in unserem Fall-Tool, die dann als „Datensätze“ bezeichnet werden, aber Sie können beispielsweise auch Microsoft Excel oder sogar Code verwenden.

In Excel hätten Sie beispielsweise eine Liste von Zeilen mit Seed-Daten. In Spalte A könnten Sie eine Excel-Funktion wie =B..&"|"&C..& "|" & ... was alles verkettet und für das Laden durch ein Ladewerkzeug geeignet macht.

Zum Beispiel könnten Sie im Code einen Aufruf wie:

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

Das Excel ist ein bisschen schwer unter Versionskontrolle zu bringen, sodass mehrere Benutzer gleichzeitig Inhalte ändern können. Der Ansatz mit Code ist sehr einfach.

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