Database versioning. Brainstorm.

Ontwerp
Ik maak een applicatie (bv in Gambas3), en gebruik een mariadb databank om de gegevens op te slaan.
Ik exporteer de structuur en bewaar die mee in de broncode om dat databank terug op te kunnen bouwen.
De vorige wordt overschreven, alleen de huidige, bij de software passende versie databank.sql wordt hier bewaard. Door het versiebeheersysteem (Git), kan je teruggaan naar oudere software versies, en dan heb je daar ook altijd de bijpassende databank struktuur bij.

Verandering
Als er een verandering gebeurt aan de code en aan de “database structure”, moet ik ergens kunnen bijhouden welke versie van de database struktuur dit is (zeker als mogelijk verschillende applicaties of versies van software gebruikt worden om die aan te spreken).

Een logische plaats zou zijn: in de database zelf.

De wijziging aan de database moet kunnen gedetecteerd worden door de software; en als maar 1 software die databank gebruikt, zou de software die ook (automatisch) kunnen aanpassen/opwaarderen, of de juiste aanpassing kunnen suggereren.
Upgrade/Downgrade: als er een upgrade script is, ook een downgrade script voor ingeval onverwachte problemen (in productie).

Het zou goed zijn als de toepassing de databank struktuur checkt bij het opstarten, dan kan er geen te oude code draaien met een niet meer kloppende nieuwere versie van de databank.

De software moet dus ook weten voor welke versie van databank ze gemaakt is; bv met een constante gedefinieerd in Main “dBVersion = 10”.

Als er een “library” gebruikt wordt om de database te benaderen kan dat daarin.

Vorm
Hoe gedetailleerd moet de database struktuur versienummering zijn?
bv:
Db is aangemaakt, is versie 1, Db v1
Db is aangepast, extra tabel, Db v 2
Db heeft extra index gekregen, Db v2.1
Nog een extra index gekregen, Db v2.2
Extra velden in tabel, Db v 3.0
Extra velden krijgen index, Db v 3.1
Tabel bijgemaakt, Db v 4.0
Velden bijgemaakt daarin, Db v 5.0
Nog een tabel extra Db v6.0

De hoofdversie vereist overeenkomstige wijziging aan de code die de data gebruikt.
Een minor versienummer levert bv een praktische versnelling op, maar geen code wijziging?

Waarschuwing
– major versienummer verschil: waarschuwing en afsluiten/readonly (?).
– minor versienummer verschil: waarschuwing en verderwerken.

Bij major aanpassing:
– telkens de database structuur bij de broncode, dan kan in principe vanaf die struktuur vertrokken worden bij nieuwe installatie van het geheel (dus ook nieuwe databank).
– de code om de database op deze stand te brengen vanuit de vorige toestand.
Dus bij de developer moet de database-wijziging gebeuren met code, dezelfde die mee geleverd wordt als upgrade code voor de gebruiker. Dat zal niet altijd kunnen, als er dingen uitgeprobeerd worden bij development; maar uiteindelijk moet de developer dan toch de vorige volle versie terugzetten en een upgrade script maken tot de gewenste toestand.

Bij minor aanpassing:
– telkens de database structuur bij de broncode, blijft.
– ook deze aanpassing als code meeleveren.

History?
– in database een history bijhouden van in gebruik geweeste versienummers, met datum, updaternaam enz.

Best eens een test maken om dat uit te proberen…