Jeg har arbejdet mest med udvikling af forretningsapplikationer og konfigurationsstyring. Dit spørgsmål er repræsentativt for udfordringerne i et sådant miljø; når du opgraderer f.eks. Microsoft Word, behøver du ikke ændre alle dokumenter med det samme fra doc til docx. Og dokumenterne har endda en mere simpel struktur en fuld relationsdatabase.
Ikke tilfældet for forretningsapplikationer; brugere springer udgivelser over, foretager uautoriserede ændringer i datamodellen, og systemet skal blive ved med at køre og levere de korrekte tal...
Vi bruger til vores egne applikationer (den største er som 600 tabeller) et selvudviklet CASE-værktøj, som inkluderer forgrening/sammenfletning, men fremgangsmåden kan også udføres manuelt.
Versioneringsdatamodel
Datamodellen kan nedskrives på en struktureret måde. For eksempel som tabelindhold (CSV, der skal indlæses i en tabel med metadata) eller som kode, der registrerer versionen i brug og tilføjer kolonner og tabeller, når de mangler, inklusive ikke-trivielle migreringer.
Dette tillader endda flere brugere på samme tid at ændre datamodellen.
Når du bruger auto-detektion (f.eks. bruger vi et kald med navnet "verify_column" i stedet for "add_column"), tillader dette endda problemfri migrering uafhængigt af det udgivelsesnummer, kunden starter opgraderingen fra. En sådan procedure analyserer tabellen, der skal ændres, og udsteder den korrekte DDL, såsom alter table t1 add col1 number not null når en kolonne mangler, eller alter table t1 modify col1 not null når kolonnen allerede var til stede, men nullbar.
Til Oracle og SQL Server kan jeg give dig et par eksempler på procedurer. I MySQL ville jeg kode dette ved at bruge et sprog på klientsiden, helst OS-uafhængig for at tillade installationer at køre på Windows og Linux. Måske bruger du Apache Ant, når du har erfaring med det.
Versioneringsdata
Vi opdeler tabellerne i fire kategorier:
- R:referencedata; data, som applikationsstedet skal levere, før han rent faktisk bruger systemet. For eksempel finanskontokoder. Referencedataene ændrer sig sjældent, efter at de er gået live og vokser ikke konstant i størrelse. Indholdet afspejler webstedets forretningsmodel, hvor applikationen bruges.
- T:transaktionsdata; data webstedet registrerer, ændrer og fjerner under brug af applikationen. For eksempel hovedbogsposter. Transaktionsdataene starter ved 0 og vokser kontinuerligt. Når virksomheden fordobler i omsætning, fordobles transaktionsdata også.
- S:seedet data; data, der IKKE vedligeholdes af brugeren på webstedet, men leveres og vedligeholdes af den udviklende part. I bund og grund er dette kode omdannet til data. For eksempel står 'F' for 'Female'. Fejl i seedede data kan føre til systemfejl.
- O:resten (ideelt ikke nødvendigt, da de er tekniske, men nogle systemer kræver en midlertidig tabel A eller en ridse tabel B).
Indholdet af tabeller i kategori 'S' (seeded data) er placeret under versionskontrol. Vi registrerer disse normalt som metadata i vores case-værktøj, så kaldet 'datasæt', men du kan også bruge for eksempel Microsoft Excel eller endda kode.
For eksempel vil du i Excel have en liste over rækker af seeded data. I kolonne A kan du indtaste en Excel-funktion som =B..&"|"&C..& "|" & ... som sammenkæder alt og gør det velegnet til lastning med et læsseværktøj.
For eksempel i kode kan du have et opkald som:
verifySeed('TABLE_A', 'CODE', 'VALUE')
Excel er lidt svært at bringe under versionskontrol, hvilket giver flere brugere mulighed for at ændre indhold på samme tid. Fremgangsmåden med kode er meget enkel.
Husk også at tilføje funktioner til at fjerne forældede seedede data. For eksempel ved eksplicit at angive forældede seedede data eller ved automatisk at fjerne alle seedede data, der findes i tabellerne, men som ikke blev berørt af den seneste installation.