Jag har arbetat mest med affärsapplikationsutveckling och konfigurationshantering. Din fråga är representativ för utmaningarna i en sådan miljö; när du uppgraderar till exempel Microsoft Word behöver du inte ändra alla dokument direkt från doc till docx. Och dokumenten har till och med en enklare struktur en fullständig relationsdatabas.
Inte så för affärsapplikationer; användare hoppar över releaser, gör obehöriga ändringar i datamodellen och systemet måste fortsätta att köra och ge rätt siffror...
Vi använder för våra egna applikationer (den största är som 600 tabeller) ett egenutvecklat CASE-verktyg som inkluderar förgrening/sammanslagning, men tillvägagångssättet kan också göras manuellt.
Versioneringsdatamodell
Datamodellen kan skrivas ner på ett strukturerat sätt. Till exempel som tabellinnehåll (CSV som ska laddas i en tabell med metadata) eller som kod som upptäcker versionen som används och lägger till kolumner och tabeller när de saknas, inklusive icke-triviala migreringar.
Detta tillåter till och med flera användare samtidigt att ändra datamodellen.
När du använder automatisk identifiering (till exempel använder vi ett anrop som heter "verify_column" istället för "add_column"), tillåter detta till och med smidig migrering oberoende av releasenummer som kunden startar uppgraderingen från. En sådan procedur analyserar tabellen som ska ändras och utfärdar rätt DDL som t.ex. alter table t1 add col1 number not null när en kolumn saknas eller alter table t1 modify col1 not null när kolumnen redan fanns men nullbar.
För Oracle och SQL Server kan jag ge dig några exempel på procedurer. I MySQL skulle jag koda detta med ett språk på klientsidan, helst OS-oberoende för att tillåta installationer att köras på Windows och Linux. Kanske använder du Apache Ant när du har erfarenhet av det.
Versioneringsdata
Vi delar upp borden i fyra kategorier:
- R:referensdata; data som applikationssidan måste tillhandahålla innan han faktiskt använder systemet. Till exempel huvudbokskontokoder. Referensdata ändras sällan efter att de släppts och växer inte kontinuerligt i storlek. Innehållet återspeglar webbplatsens affärsmodell där applikationen används.
- T:transaktionsdata; data som webbplatsen registrerar, ändrar och tar bort under användning av applikationen. Till exempel huvudboksposter. Transaktionsdata börjar vid 0 och växer kontinuerligt. När företaget fördubblar sina intäkter fördubblas transaktionsdata också.
- S:seeded data; data som INTE underhålls av användaren på webbplatsen utan tillhandahålls och underhålls av den utvecklande parten. I huvudsak är detta kod som förvandlas till data. Till exempel står "F" för "Female". Fel i sådd data kan leda till systemfel.
- O:resten (helst behövs inte, eftersom de är tekniska, men vissa system kräver en tillfällig tabell A eller en skraptabell B).
Innehållet i tabeller i kategori 'S' (seeded data) placeras under versionskontroll. Vi registrerar normalt dessa som metadata i vårt ärendeverktyg, då namnet 'dataset', men du kan också använda till exempel Microsoft Excel eller till och med kod.
Till exempel, i Excel skulle du ha en lista med rader med seedad data. I kolumn A kan du ange en Excel-funktion som =B..&"|"&C..& "|" & ... som sammanfogar allt och gör det lämpligt för lastning med ett lastverktyg.
Till exempel i kod kan du ha ett samtal som:
verifySeed('TABLE_A', 'CODE', 'VALUE')
Excel är lite svårt att få under versionskontroll så att flera användare kan ändra innehåll samtidigt. Tillvägagångssättet med kod är mycket enkelt.
Kom ihåg att också lägga till funktioner för att ta bort föråldrad seedad data. Till exempel genom att uttryckligen lista föråldrade seedade data eller genom att automatiskt ta bort all seedad data som finns i tabellerna men som inte berördes av den senaste installationen.