Martin Fowler skrev min favoritartikel om ämnet, http://martinfowler.com/articles/evodb.html. Jag väljer att inte lägga in schemadumpar under versionskontroll som alumb och andra föreslår eftersom jag vill ha ett enkelt sätt att uppgradera min produktionsdatabas.
För en webbapplikation där jag kommer att ha en enda produktionsdatabasinstans använder jag två tekniker:
Skript för databasuppgradering
En sekvensdatabasuppgraderingsskript som innehåller den DDL som krävs för att flytta schemat från version N till N+1. (Dessa går i ditt versionskontrollsystem.) En _version_history_-tabell, något liknande
create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
får en ny post varje gång ett uppgraderingsskript körs som motsvarar den nya versionen.
Detta säkerställer att det är lätt att se vilken version av databasschemat som finns och att databasuppgraderingsskript körs endast en gång. Återigen, dessa är inte databasdumpar. Snarare representerar varje skript ändringarna krävs för att flytta från en version till nästa. De är skriptet som du applicerar på din produktionsdatabas för att "uppgradera" den.
Sandlådesynkronisering för utvecklare
- Ett skript för att säkerhetskopiera, sanera och krympa en produktionsdatabas. Kör detta efter varje uppgradering till produktions-DB.
- Ett skript för att återställa (och justera, om nödvändigt) säkerhetskopian på en utvecklares arbetsstation. Varje utvecklare kör det här skriptet efter varje uppgradering till produktions-DB.
En varning:Mina automatiserade tester körs mot en schemakorrekt men tom databas, så detta råd kommer inte att passa dina behov perfekt.