Martin Fowler hat meinen Lieblingsartikel zu diesem Thema geschrieben, http://martinfowler.com/articles/evodb.html. Ich entscheide mich dafür, Schema-Dumps nicht als alumb unter Versionskontrolle zu stellen und andere schlagen vor, weil ich meine Produktionsdatenbank auf einfache Weise aktualisieren möchte.
Für eine Webanwendung, in der ich eine einzelne Produktionsdatenbankinstanz habe, verwende ich zwei Techniken:
Datenbank-Upgrade-Skripte
Eine Sequenz von Datenbank-Upgradeskripten, die die DDL enthalten, die zum Verschieben des Schemas von Version N auf N+1 erforderlich ist. (Diese gehen in Ihr Versionskontrollsystem.) Eine _version_history_-Tabelle, so etwas wie
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
erhält jedes Mal, wenn ein Upgrade-Skript ausgeführt wird, einen neuen Eintrag, der der neuen Version entspricht.
Dadurch wird sichergestellt, dass leicht erkennbar ist, welche Version des Datenbankschemas vorhanden ist, und dass Datenbank-Upgrade-Skripts nur einmal ausgeführt werden. Auch diese sind nicht Datenbank-Dumps. Vielmehr stellt jedes Skript die Änderungen dar notwendig, um von einer Version zur nächsten zu wechseln. Sie sind das Skript, das Sie auf Ihre Produktionsdatenbank anwenden, um sie zu "aktualisieren".
Entwickler-Sandbox-Synchronisierung
- Ein Skript zum Sichern, Bereinigen und Verkleinern einer Produktionsdatenbank. Führen Sie dies nach jedem Upgrade auf die Produktions-DB aus.
- Ein Skript zum Wiederherstellen (und ggf. Optimieren) der Sicherung auf der Arbeitsstation eines Entwicklers. Jeder Entwickler führt dieses Skript nach jedem Upgrade auf die Produktionsdatenbank aus.
Eine Einschränkung:Meine automatisierten Tests werden mit einer schemakorrekten, aber leeren Datenbank ausgeführt, sodass dieser Ratschlag nicht perfekt Ihren Anforderungen entspricht.
