Wie können Sie Änderungen an SQL-Tabellen nachverfolgen?

Wie können Sie in einem Entwicklerteam, in dem jeder Änderungen an lokalen Tabellen und Entwicklungstabellen vornimmt, alle Änderungen synchron halten? Eine zentrale Protokolldatei, in der jeder seine SQL-Änderungen speichert? Eine Wiki-Seite zum Verfolgen von alter table-Anweisungen, einzelnen .sql-Dateien, die die Entwickler ausführen können, um ihre lokalen Datenbanken auf die neueste Version zu bringen? Ich habe einige dieser Lösungen verwendet und bin bemüht, eine gute, solide Lösung zusammenzustellen, die funktioniert. Ich würde mich über Ihre Ideen freuen.

Ich verwende ein codebasiertes Tool für die Datenbankmigration und behalte den Migrationscode in der Versionsverwaltung.

Durch die Verwendung von Zeitstempeln als Versionsnummern kann eine beliebige Anzahl von Entwicklern Migrationen nach Belieben hinzufügen, und wir können das Migrationstool sicher für jede Kopie unserer Datenbank ausführen.

Früher habe ich SQL-Skripte unter Versionskontrolle verwendet, aber der Code-basierte Ansatz ist viel einfacher zu handhaben, da sie sich alle an einem logischen Ort befinden und alle erforderlichen Skripte mit einem einzigen Befehl ausführen können.

Ich mache das nicht selbst, aber einige Entwickler verwalten eine Sammlung von SQL-Skripten unter Versionskontrolle, die bei ihrer Ausführung die Datenbanktabellen zu Testzwecken neu erstellen und eine leere Datenbank für Produktionszwecke erstellen können.

Dieselbe Technik kann verwendet werden, um die Datenbank beim Kunden zu versionieren, wenn Felder oder Tabellen hinzugefügt oder entfernt werden müssen oder Datenumwandlungen stattfinden müssen.

Erstellen Sie Skripte unter Versionskontrolle und kontinuierlicher Integration, um sie zu überprüfen

Ein Ansatz, der für mich funktioniert hat, war, dass jeder Entwickler mit seinem eigenen Schema arbeitet, mit dem er machen kann, was er will. Ihr Schema war zerstörbar und mit Testdaten gefüllt, die aus einem versionskontrollierten Satz von Skripten stammen, zu denen alle Entwickler beigetragen haben.

Bei der nächtlichen kontinuierlichen Integrationserstellung wurde die neueste Version aller Skripts verwendet und versucht, eine zusammenhängende Testdatenbank daraus zu erstellen. Die Anwendung wurde dann einer Reihe von Integrations- und Funktionstests unterzogen, um sicherzustellen, dass das aktuelle Schema mit dem aktuellen Release-Kandidaten übereinstimmt.

Bevor wir diesen Weg eingeschlagen haben, gab es ein ziemlich solides Datenbankdesign und ein DBA hat immer ein Auge auf die Dinge geworfen, um zu verhindern, dass Entwickler durch Denormalisierung und andere Schrecken verrückt werden.

Die Versionskontrolle hat hier immens geholfen, da Änderungen an den Skripten sofort erkennbar waren. Wir haben auch eine Datenbanktabelle verwendet VERSION, um den Gesamtstatus der Datenbank zu ermitteln. Dies war eine einfache Ganzzahlsequenz, die keiner bestimmten Anwendung zugeordnet war.

Insgesamt hat es gut funktioniert und bedeutet, dass Entwickler keine Angst mehr davor haben, die Persistenzstufen zu ändern, da sie ihre eigenen Schemata immer zurücksetzen konnten, ohne andere zu beeinträchtigen.

Wenn Sie sich in einem MS-Shop befinden, verfügt Visual Studio 2010 über einige nützliche Tools zur Versionskontrolle von Datenbanken, mit denen auch Änderungs- / Bereitstellungsskripten generiert werden können, die auf den Unterschieden zwischen zwei Datenbanken basieren.

Neben der Versionskontrolle von Schemata und anderen SQL-Skripten besteht eine weitere praktische Praxis darin , eine 'Schemaversion'-Tabelle in der eigentlichen Datenbank zu verwalten .

create table schema_migrations (
    `appliedAt` timestamp not null default CURRENT_TIMESTAMP,
    `migrationCode` varchar(256) not null,
    `extraNotes` varchar(256),
    primary key (`migrationCode`)
)

Doctrine hat ein großartiges Migrationstool: http://www.doctrine-project.org/documentation/manual/1_2/en/migrations . Das Beste daran ist, dass sie automatisch generiert wurden oder einfach von Hand codiert werden können.

Der Ansatz, den ich verwende, besteht darin, eine Tabelle für Parameter bereitzustellen. Diese Tabelle enthält ein Name / Wert-Paar für die Version, in der sich die Datenbank befindet. Dies bietet mir zwei Vorteile: Ich kann überprüfen, ob ein Datenbank-Fix über die Anwendung angewendet wurde, und ich kann diesen Wert für meine SQL-Skripten verwenden.

Das SQL-Skript erstellt neue Tabellen, ändert Spalten und die erforderliche Arbeit in der Datenbank, um das Skript aus der vorherigen Version zu promoten. Idealerweise hätte ich auch ein Rollback-Skript, aber meistens nicht.

Übrigens wurde dieser gesamte Ansatz im Rahmen von Ruby on Rails einschließlich der Rollback-Skripte automatisiert. Ich mag die Idee davon, aber nicht alle Frameworks tun das. Wenn ich Ruby on Rails nicht verwende, verwende ich den oben beschriebenen Ansatz.