Gibt es ein Versionskontrollsystem für Datenbankstrukturänderungen?

08-06-2019
|

Frage

Ich stoße oft auf das folgende Problem.

Ich arbeite an einigen Änderungen an einem Projekt, die neue Tabellen oder Spalten in der Datenbank erfordern.Ich nehme die Datenbankänderungen vor und setze meine Arbeit fort.Normalerweise denke ich daran, die Änderungen aufzuschreiben, damit sie auf dem Live-System repliziert werden können.Allerdings erinnere ich mich nicht immer daran, was ich geändert habe, und ich erinnere mich nicht immer daran, es aufzuschreiben.

Also mache ich einen Push auf das Live-System und erhalte eine große, offensichtliche Fehlermeldung, dass es keine gibt NewColumnX, pfui.

Gibt es ein Versionskontrollsystem für Datenbanken, auch wenn dies in dieser Situation möglicherweise nicht die beste Vorgehensweise ist?Die spezifische Datenbanktechnologie ist mir egal.Ich möchte nur wissen, ob es einen gibt.Wenn es zufällig mit MS SQL Server funktioniert, dann großartig.

Lösung

In Ruby on Rails gibt es ein Konzept von a Migration – ein schnelles Skript zum Ändern der Datenbank.

Sie generieren eine Migrationsdatei, die Regeln zum Erhöhen der Datenbankversion (z. B. Hinzufügen einer Spalte) und Regeln zum Herabstufen der Version (z. B. Entfernen einer Spalte) enthält.Jede Migration ist nummeriert und eine Tabelle verfolgt Ihre aktuelle Datenbankversion.

Zu nach oben migrieren, führen Sie einen Befehl namens „db:migrate“ aus, der Ihre Version überprüft und die erforderlichen Skripte anwendet.Sie können auf ähnliche Weise nach unten migrieren.

Die Migrationsskripte selbst werden in einem Versionskontrollsystem gespeichert. Wenn Sie die Datenbank ändern, checken Sie ein neues Skript ein, und jeder Entwickler kann es anwenden, um seine lokale Datenbank auf die neueste Version zu bringen.

Andere Tipps

Ich bin ein bisschen altmodisch, da ich Quelldateien zum Erstellen der Datenbank verwende.Es gibt eigentlich zwei Dateien – project-database.sql und project-updates.sql – die erste für das Schema und die persistenten Daten und die zweite für Änderungen.Natürlich unterliegen beide der Quellcodeverwaltung.

Wenn sich die Datenbank ändert, aktualisiere ich zuerst das Hauptschema in project-database.sql und kopiere dann die relevanten Informationen in die project-updates.sql, zum Beispiel ALTER TABLE-Anweisungen.Ich kann die Updates dann auf die Entwicklungsdatenbank anwenden, testen und iterieren, bis alles gut ist.Dann checken Sie die Dateien ein, testen sie erneut und wenden sie auf die Produktion an.

Außerdem habe ich normalerweise eine Tabelle in der Datenbank – Config – wie zum Beispiel:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Dann füge ich dem Update-Bereich Folgendes hinzu:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

Der db_version wird nur geändert, wenn die Datenbank neu erstellt wird, und die db_revision Gibt mir einen Hinweis darauf, wie weit die Datenbank von der Grundlinie entfernt ist.

Ich könnte die Updates in ihren eigenen separaten Dateien behalten, aber ich habe mich dafür entschieden, sie alle zusammenzufassen und relevante Abschnitte mit Ausschneiden und Einfügen zu extrahieren.Etwas mehr Ordnung ist angebracht, d. h. entfernen Sie „:“ aus $Revision 1.1 $, um sie einzufrieren.

MyBatis (ehemals iBatis) hat eine Schemamigration, Tool zur Verwendung in der Befehlszeile.Es ist in Java geschrieben, kann jedoch mit jedem Projekt verwendet werden.

Um ein gutes Datenbank-Änderungsmanagement zu erreichen, müssen wir einige wichtige Ziele identifizieren.Daher zielt das MyBatis Schema Migration System (oder kurz MyBatis Migrations) darauf ab:

Arbeiten Sie mit jeder neuen oder vorhandenen Datenbank
Nutzen Sie das Versionsverwaltungssystem (z. B.Subversion)
Ermöglichen Sie gleichzeitigen Entwicklern oder Teams, unabhängig zu arbeiten
Sorgen Sie dafür, dass Konflikte gut sichtbar und leicht beherrschbar sind
Vorwärts- und Rückwärtsmigration ermöglichen (entwickeln bzw. devolvieren)
Machen Sie den aktuellen Stand der Datenbank leicht zugänglich und verständlich
Ermöglichen Sie Migrationen trotz Zugriffsprivilegien oder Bürokratie
Arbeiten Sie mit jeder Methodik
Fördert gute, konsistente Praktiken

Redgate hat ein Produkt namens SQL-Quellcodeverwaltung.Es lässt sich in TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce und Git integrieren.

Ich empfehle sehr SQL-Delta.Ich verwende es einfach, um die Diff-Skripte zu generieren, wenn ich mit dem Codieren meiner Funktion fertig bin, und überprüfe diese Skripte in meinem Quellcodeverwaltungstool (Mercurial :))

Sie haben sowohl eine SQL Server- als auch eine Oracle-Version.

Ich wundere mich, dass niemand das Open-Source-Tool erwähnt hat Flüssigkeitsbasis Das ist Java-basiert und sollte für fast jede Datenbank funktionieren, die JDBC unterstützt.Im Vergleich zu Rails wird XML anstelle von Ruby verwendet, um die Schemaänderungen durchzuführen.Obwohl ich XML für domänenspezifische Sprachen nicht mag, besteht der sehr coole Vorteil von XML darin, dass Liquibase weiß, wie bestimmte Vorgänge wie z

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Sie müssen sich also nicht selbst darum kümmern

Auch reine SQL-Anweisungen oder Datenimporte werden unterstützt.

Die meisten Datenbank-Engines sollten das Speichern Ihrer Datenbank in einer Datei unterstützen.Ich weiß jedenfalls, dass MySQL das tut.Dabei handelt es sich lediglich um eine Textdatei, die Sie an Subversion oder was auch immer Sie verwenden, senden können.Es wäre auch einfach, einen Diff für die Dateien auszuführen.

Wenn Sie SQL Server verwenden, ist Data Dude (auch bekannt als Database Edition von Visual Studio) kaum zu schlagen.Sobald Sie den Dreh raus haben, ist es ein Kinderspiel, einen Schemavergleich zwischen Ihrer quellgesteuerten Version der Datenbank und der Version in der Produktion durchzuführen.Und mit einem Klick können Sie Ihre DIFF-DDL generieren.

Es gibt eine Anleitung Video Auf MSDN ist das sehr hilfreich.

Ich kenne DBMS_METADATA und Toad, aber wenn jemand einen Data Dude für Oracle entwickeln könnte, wäre das Leben wirklich süß.

Lassen Sie Ihre anfänglichen Tabellenanweisungen im Versionscontroller erstellen und fügen Sie dann Änderungen an den Tabellenanweisungen hinzu. Bearbeiten Sie jedoch niemals Dateien, sondern nur mehrere Änderungen, die idealerweise der Reihe nach oder sogar als „Änderungssatz“ benannt werden, damit Sie alle Änderungen für eine bestimmte Bereitstellung finden können.

Der schwierigste Teil, den ich sehe, ist die Verfolgung von Abhängigkeiten, z. B. muss für eine bestimmte Bereitstellung möglicherweise Tabelle B vor Tabelle A aktualisiert werden.

Für Oracle verwende ich Kröte, wodurch ein Schema in eine Reihe diskreter Dateien (z. B. eine Datei pro Tabelle) gespeichert werden kann.Ich habe einige Skripte, die diese Sammlung in Perforce verwalten, aber ich denke, dass dies in nahezu jedem Revisionskontrollsystem problemlos möglich sein sollte.

Schauen Sie sich das Oracle-Paket DBMS_METADATA an.

Insbesondere die folgenden Methoden sind besonders nützlich:

DBMS_METADATA.GET_DDL
DBMS_METADATA.SET_TRANSFORM_PARAM
DBMS_METADATA.GET_GRANTED_DDL

Sobald Sie mit ihrer Funktionsweise vertraut sind (ziemlich selbsterklärend), können Sie ein einfaches Skript schreiben, um die Ergebnisse dieser Methoden in Textdateien zu speichern, die unter Quellcodeverwaltung gestellt werden können.Viel Glück!

Ich bin mir nicht sicher, ob es für MSSQL etwas so Einfaches gibt.

Ich schreibe meine DB-Release-Skripte parallel zum Codieren und behalte die Release-Skripte in einem projektspezifischen Abschnitt in SS.Wenn ich eine Änderung am Code vornehme, die eine Datenbankänderung erfordert, aktualisiere ich gleichzeitig das Release-Skript.Vor der Veröffentlichung führe ich das Veröffentlichungsskript auf einer sauberen Entwicklungsdatenbank aus (strukturell aus der Produktion kopiert) und führe meine letzten Tests damit durch.

Ich mache das seit Jahren hin und wieder – ich verwalte Schemaversionen (oder versuche es zu verwalten).Die besten Ansätze hängen von den Tools ab, über die Sie verfügen.Wenn Sie das Quest Software-Tool „Schema Manager“ erhalten können, sind Sie in einer guten Verfassung.Oracle hat ein eigenes, minderwertiges Tool, das auch „Schema Manager“ heißt (verwirrend?), das ich nicht empfehle.

Ohne ein automatisiertes Tool (siehe andere Kommentare hier zu Data Dude) verwenden Sie Skripte und DDL-Dateien direkt.Wählen Sie einen Ansatz, dokumentieren Sie ihn und befolgen Sie ihn strikt.Ich mag die Möglichkeit, die Datenbank jederzeit neu erstellen zu können, daher bevorzuge ich einen vollständigen DDL-Export der gesamten Datenbank (wenn ich der DBA bin) oder des Entwicklerschemas (wenn ich im Produkt bin). -Entwicklungsmodus).

PLSQL Developer, ein Tool von All Arround Automations, verfügt über ein Plugin für Repositorys, das mit Visual Source Safe gut (aber nicht großartig) funktioniert.

Aus dem Internet:

Das Versionskontroll-Plug-In bietet eine enge Integration zwischen der PL/SQL-Entwickler-IDE >> und jedem Versionskontrollsystem, das die Microsoft SCC-Schnittstellenspezifikation unterstützt.>>Dazu gehören die gängigsten Versionskontrollsysteme wie Microsoft Visual SourceSafe, Merant PVCS und MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

ER Studio ermöglicht es Ihnen, Ihr Datenbankschema in das Tool umzuwandeln und es dann mit Live-Datenbanken zu vergleichen.

Beispiel:Kehren Sie Ihr Entwicklungsschema in ER Studio um – vergleichen Sie es mit der Produktion und es werden alle Unterschiede aufgelistet.Es kann die Änderungen per Skript ausführen oder sie einfach automatisch durchsetzen.

Sobald Sie ein Schema in ER Studio haben, können Sie entweder das Erstellungsskript speichern oder es als proprietäre Binärdatei speichern und in der Versionskontrolle speichern.Wenn Sie jemals zu einer früheren Version des Schemas zurückkehren möchten, schauen Sie es sich einfach an und übertragen Sie es auf Ihre Datenbankplattform.

Es gibt ein PHP5-„Datenbankmigrations-Framework“ namens Ruckusing.Ich habe es nicht benutzt, aber das Beispiele Zeigen Sie die Idee: Wenn Sie die Sprache verwenden, um die Datenbank nach Bedarf zu erstellen, müssen Sie nur die Quelldateien verfolgen.

Sie können verwenden Microsoft SQL Server-Datentools in Visual Studio, um Skripte für Datenbankobjekte als Teil eines SQL Server-Projekts zu generieren.Anschließend können Sie die Skripts mithilfe der in Visual Studio integrierten Versionsverwaltungsintegration zur Quellcodeverwaltung hinzufügen.Außerdem ermöglichen Ihnen SQL Server-Projekte, die Datenbankobjekte mithilfe eines Compilers zu überprüfen und Bereitstellungsskripts zu generieren, um eine vorhandene Datenbank zu aktualisieren oder eine neue zu erstellen.

Wir haben verwendet MS Team System Database Edition mit ziemlich gutem Erfolg.Es lässt sich mehr oder weniger nahtlos in die TFS-Versionskontrolle und Visual Studio integrieren und ermöglicht uns die einfache Verwaltung gespeicherter Prozesse, Ansichten usw.Die Konfliktlösung kann mühsam sein, aber der Versionsverlauf ist vollständig, sobald er erledigt ist.Danach sind Migrationen zur Qualitätssicherung und Produktion äußerst einfach.

Man kann jedoch mit Fug und Recht sagen, dass es sich um ein Produkt der Version 1.0 handelt und einige Probleme aufweist.

Schema Compare for Oracle ist ein Tool, das speziell für die Migration von Änderungen aus unserer Oracle-Datenbank in eine andere entwickelt wurde.Bitte besuchen Sie die URL unten für den Download-Link, über den Sie die Software für eine voll funktionsfähige Testversion nutzen können.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

Da es kein VCS für Tabellenänderungen gibt, habe ich sie in einem Wiki protokolliert.Dann kann ich zumindest sehen, wann und warum es geändert wurde.Es ist alles andere als perfekt, da es nicht jeder macht und wir mehrere Produktversionen im Einsatz haben, aber besser als nichts.

Ich würde einen von zwei Ansätzen empfehlen.Investieren Sie zunächst in PowerDesigner von Sybase.Enterprise Edition.Sie können damit physische Datenmodelle und vieles mehr entwerfen.Es verfügt jedoch über ein Repository, mit dem Sie Ihre Modelle einchecken können.Bei jedem neuen Einchecken kann es sich um eine neue Version handeln. Es kann jede Version mit jeder anderen Version und sogar mit dem, was sich zu diesem Zeitpunkt in Ihrer Datenbank befindet, verglichen werden.Anschließend wird eine Liste aller Unterschiede angezeigt und gefragt, welche migriert werden sollen. Anschließend wird das entsprechende Skript erstellt.Es ist nicht billig, aber zum doppelten Preis ein Schnäppchen und der ROI beträgt etwa 6 Monate.

Die andere Idee besteht darin, die DDL-Prüfung zu aktivieren (funktioniert in Oracle).Dadurch wird mit jeder von Ihnen vorgenommenen Änderung eine Tabelle erstellt.Wenn Sie die Änderungen ab dem Zeitstempel abfragen, zu dem Sie Ihre Datenbankänderungen zuletzt in „prod“ verschoben haben, erhalten Sie eine geordnete Liste aller Ihrer Aktionen.Einige where-Klauseln zum Eliminieren von Nullsummenänderungen wie create table foo;gefolgt von drop table foo;und Sie können EINFACH ein Mod-Skript erstellen.Warum die Änderungen in einem Wiki behalten, das ist doppelte Arbeit?Lassen Sie die Datenbank sie für Sie verfolgen.

Zwei Buchempfehlungen:„Refactoring Databases“ von Ambler und Sadalage und „Agile Database Techniques“ von Ambler.

Jemand erwähnte Rails-Migrationen.Ich finde, dass sie auch außerhalb von Rails-Anwendungen großartig funktionieren.Ich habe sie in einer ASP-Anwendung mit SQL Server verwendet, die wir gerade auf Rails umstellen wollten.Sie checken die Migrationsskripte selbst in das VCS ein.Hier ist ein Beitrag des pragmatischen Dave Thomas zum Thema.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow