Ik heb voornamelijk gewerkt in de ontwikkeling van bedrijfsapplicaties en configuratiebeheer. Uw vraag is representatief voor de uitdagingen in zo'n omgeving; wanneer u bijvoorbeeld Microsoft Word upgradet, hoeft u niet meteen alle documenten van doc naar docx te veranderen. En de documenten hebben zelfs een meer eenvoudige structuur een volledige relatiedatabase.
Niet zo voor zakelijke toepassingen; gebruikers slaan releases over, brengen ongeautoriseerde wijzigingen aan in het datamodel en het systeem moet blijven draaien en de juiste cijfers geven...
We gebruiken voor onze eigen toepassingen (de grootste is ongeveer 600 tabellen) een zelfontwikkelde CASE-tool die vertakking/samenvoeging omvat, maar de aanpak kan ook handmatig worden gedaan.
Versiegegevensmodel
Het datamodel kan gestructureerd worden uitgeschreven. Bijvoorbeeld als tabelinhoud (CSV te laden in een tabel met metagegevens) of als code die de gebruikte versie detecteert en kolommen en tabellen toevoegt wanneer deze ontbreken, inclusief niet-triviale migraties.
Hierdoor kunnen zelfs meerdere gebruikers tegelijkertijd het datamodel wijzigen.
Wanneer u automatische detectie gebruikt (we gebruiken bijvoorbeeld een aanroep met de naam "verify_column" in plaats van "add_column"), maakt dit zelfs een soepele migratie mogelijk, onafhankelijk van het releasenummer waarvan de klant de upgrade start. Een dergelijke procedure analyseert de tabel die moet worden gewijzigd en geeft de juiste DDL uit, zoals alter table t1 add col1 number not null wanneer een kolom ontbreekt of alter table t1 modify col1 not null wanneer de kolom al aanwezig was maar nullable was.
Voor Oracle en SQL Server kan ik u enkele voorbeeldprocedures geven. In MySQL zou ik dit coderen met behulp van een client-side taal, bij voorkeur OS-onafhankelijk om installaties op Windows en Linux te laten draaien. Misschien Apache Ant gebruiken als je daar ervaring mee hebt.
Versiegegevens
We splitsen de tafels in vier categorieën:
- R:referentiegegevens; gegevens die de plaats van toepassing moet verstrekken voordat hij het systeem daadwerkelijk gebruikt. Bijvoorbeeld grootboekrekeningcodes. De referentiegegevens veranderen zelden na livegang en groeien niet continu in omvang. De inhoud weerspiegelt het bedrijfsmodel van de site waar de applicatie wordt gebruikt.
- T:transactiegegevens; gegevens die de site tijdens het gebruik van de applicatie registreert, wijzigt en verwijdert. Bijvoorbeeld grootboekposten. De transactiegegevens beginnen bij 0 en groeien continu. Wanneer het bedrijf de inkomsten verdubbelt, verdubbelen de transactiegegevens ook.
- S:gezaaide gegevens; gegevens die NIET door de gebruiker op de site worden onderhouden, maar worden verstrekt en onderhouden door de ontwikkelende partij. In wezen is dit code omgezet in gegevens. 'F' staat bijvoorbeeld voor 'Female'. Fouten in gezaaide gegevens kunnen leiden tot systeemfouten.
- O:de rest (idealiter niet nodig, omdat ze technisch zijn, maar sommige systemen hebben een tijdelijke tabel A of een kladtafel B nodig).
De inhoud van tabellen van categorie 'S' (seeded data) wordt onder versiebeheer geplaatst. Normaal gesproken registreren we deze als metadata in onze casetool, dan 'datasets' genoemd, maar je kunt ook bijvoorbeeld Microsoft Excel of zelfs code gebruiken.
In Excel zou u bijvoorbeeld een lijst met rijen met gezaaide gegevens hebben. In kolom A kunt u een Excel-functie invoeren zoals =B..&"|"&C..& "|" & ... die alles samenvoegt en geschikt maakt voor het laden door een loader-tool.
U kunt bijvoorbeeld in code een oproep hebben als:
verifySeed('TABLE_A', 'CODE', 'VALUE')
De Excel is een beetje moeilijk om onder versiebeheer te brengen, waardoor meerdere gebruikers tegelijkertijd de inhoud kunnen wijzigen. De aanpak met code is heel eenvoudig.
Vergeet niet om ook functies toe te voegen om verouderde gezaaide gegevens te verwijderen. Bijvoorbeeld door verouderde seeded-gegevens expliciet op te sommen of door automatisch alle seeded-gegevens in de tabellen te verwijderen die niet zijn aangetast door de laatste installatie.