Versioning van databases

[mithras]

Ik ben nu al lange tijd aan het denken hoe ik ook mijn database onder versiebeheer kan plaatsen. Zover ik kan zien is versioning van databases een ondergeschoven kindje. Op internet is er bizar weinig over te vinden en ik zie ook bij bedrijven dat een groot aantal van hen de database niet onder versiecontrolebeheer hebben. Tot slot is ook op GoT weinig te vinden hoe dit nu echt moet.

Vooralsnog kom ik uit op een tweetal mogelijkeden:

1. Het gebruiken van externe tools
2. Het inzetten van svn hooks

De eerste heb ik naar gekeken, maar het vereist altijd nog best wat extra acties. Er zitten gesloten, betaalde oplossingen tussen en de gebruiksvriendelijkheid is lang niet altijd op en top.
De tweede heb ik ook over zitten denken. Je zal met een hook een database dump kunnen maken, gesplitst in een structuur en een data dump. Deze schrijf je weg in je repository. Vervolgens kan je bij een checkout, update of export deze data gebruiken om je database te updaten.

De laatste lijkt me de beste optie. Omdat onze mensen of op Macs of op Linux werken, zouden bash scripts een goede mogelijkheid zijn. Je kan alleen niet zomaar een diff maken tussen de twee revisies en dat als sql uitvoeren. Hoe zal je dit moeten oplossen? Zijn er nog andere mogelijkheden?
Ik heb het idee dat broncode heel makkelijk is te beheren, maar databases een ramp zijn

[BCC]

Bij rails zit een erg goede database versiebeheer toolie op basis van migraties. Aangezien het een redelijk losstaand onderdeel is zou je dat prima kunnen misbruiken.

[ Voor 5% gewijzigd door BCC op 19-05-2009 20:28 ]

[flashin]

Waarom begin je met een fout database design? Uiteraard heb je veranderingen maar dit is, wanneer je je requirements goed bepaalt, vaak niet zo cruciaal.

Voor mijn projecten heb ik daar iig geen versiebeheer voor nodig, en mocht het echt een drastische wijziging zijn "along the way", dan maak ik wel eerst handmatig een dumpje.

[BCC]

Niemand is perfect, dus een perfect database schema is ook een enorme utopie. Daarnaast wil je ook wel eens nieuwe features aan je applicatie toevoegen, waardoor je toch echt database migraties moet doen. Als je meer dan 10 instanties hebt, wil je dat echt niet meer met het handje doen.

[ Voor 11% gewijzigd door BCC op 19-05-2009 20:31 ]

[mithras]

BCC schreef op dinsdag 19 mei 2009 @ 20:27:
Bij rails zit een erg goede database versiebeheer toolie op basis van migraties. Aangezien het een redelijk losstaand onderdeel is zou je dat prima kunnen misbruiken.

Ik heb er wel vaker van gehoord. De projecten die ik doe zijn slechts php trouwens. Maar als het echt zo goed is als het werkt, wil ik het wel eens gaan proberen.

Er is trouwens wel een proposal binnen ZF (waar onze applicatie bovenop ligt): http://framework.zend.com...chema_Manager+-+Rob+Allen wat een soortgelijke implementatie heeft. Alleen is er buiten een proposal nog niets bruikbaars. Dit proposal kende ik al, maar ik zie ineens twee andere tools bij de comments staan: dmigrations, maar dat is voor Django (en dus Python) en DatabaseScheme van eZ.

flashin schreef op dinsdag 19 mei 2009 @ 20:28:
Waarom begin je met een fout database design? Uiteraard heb je veranderingen maar dit is, wanneer je je requirements goed bepaalt, vaak niet zo cruciaal.

Voor mijn projecten heb ik daar iig geen versiebeheer voor nodig, en mocht het echt een drastische wijziging zijn "along the way", dan maak ik wel eerst handmatig een dumpje.

Tja, het komt ook niet zo vaak voor. Maar er kunnen toch wel problemen komen als er ineens wel een wijziging komt. Verder wil ik ook meer gaan doen met versiebeheer.

Allereerst gaan we voor alle klanten een eigen branch aanmaken. Er moeten vaak specifieke onderdelen ontwikkeld worden of modules net een beetje aangepast. Dit kan prima, maar dan moet de data van al die verschillende branches wel beheerd worden.
Verder wil ik ook graag per module de tabellen gaan beheren in svn, als dat mogelijk is. De ene klant wil namelijk andere modules dan de andere. Dat betekent dat er per module een configuratie van verschillende tabellen nodig is. Het zou mooi zijn om dit ook apart te beheren.

[Alain]

mithras schreef op dinsdag 19 mei 2009 @ 21:11:
Allereerst gaan we voor alle klanten een eigen branch aanmaken. Er moeten vaak specifieke onderdelen ontwikkeld worden of modules net een beetje aangepast. Dit kan prima, maar dan moet de data van al die verschillende branches wel beheerd worden.

Kun je niet beter uitgaan van stabiele parametreerbare universele modules en stabiele specifieke modules?

Wat ik uit je verhaal begrijp is dat je elk produkt van een klant als specifieke vertakking van het product wilt zien en apart wilt beheren, ondanks dat het produkt dezelfde basis en updates heeft. Dat lijkt me niet het idee van versiebeheer.

[BCC]

mithras schreef op dinsdag 19 mei 2009 @ 21:11:
[...]
Ik heb er wel vaker van gehoord. De projecten die ik doe zijn slechts php trouwens. Maar als het echt zo goed is als het werkt, wil ik het wel eens gaan proberen.

Kijk anders eens naar Cake PHP, dat is het lichterlijk gehandicapte broertje van Ruby on Rails. Die hebben denk ik ook wel een variant van dit soort database migraties.

Tja, het komt ook niet zo vaak voor. Maar er kunnen toch wel problemen komen als er ineens wel een wijziging komt. Verder wil ik ook meer gaan doen met versiebeheer.

Allereerst gaan we voor alle klanten een eigen branch aanmaken. Er moeten vaak specifieke onderdelen ontwikkeld worden of modules net een beetje aangepast. Dit kan prima, maar dan moet de data van al die verschillende branches wel beheerd worden.
Verder wil ik ook graag per module de tabellen gaan beheren in svn, als dat mogelijk is. De ene klant wil namelijk andere modules dan de andere. Dat betekent dat er per module een configuratie van verschillende tabellen nodig is. Het zou mooi zijn om dit ook apart te beheren.

Houd je er wel rekening mee dat elk stuk maatwerk op je generieke kern een verdubbeling in je onderhoud betekend? (Wat Alain zei). Klantspecifieke database migraties zijn namelijk nog een heel stuk ingewikkelder dan generieke migraties.

[ Voor 3% gewijzigd door BCC op 19-05-2009 22:30 ]

[mithras]

AlainS schreef op dinsdag 19 mei 2009 @ 21:58:
[...]

Kun je niet beter uitgaan van stabiele parametreerbare universele modules en stabiele specifieke modules?

Wat ik uit je verhaal begrijp is dat je elk produkt van een klant als specifieke vertakking van het product wilt zien en apart wilt beheren, ondanks dat het produkt dezelfde basis en updates heeft. Dat lijkt me niet het idee van versiebeheer.

Eigenlijk bestaat het product uit drie onderdelen: het Zend Framework, onze eigen middleware en specifieke op maat gemaakte modules voor de klant. De eerste symlinken we en staat dus niet in svn. De tweede wordt ontwikkeld in de trunk en de laatste wordt ontwikkeld in een eigen branch.

Deze keuze is gemaakt omdat alle klanten het altijd net iets anders willen. Een parametreerbare module kost altijd meer resources. Daarom zetten we de modules universeel op, maar moeten we aanpassingen in de source maken om het onderdeel op maat te krijgen. Dan hebben we wel het meest compacte systeem.

Eigenlijk zal de middleware naar verloop van tijd niet tot nauwelijks meer veranderen. Als er toch aanpassingen zijn tijdens de ontwikkeling voor een klant, mergen we vanuit trunk de branch versie. Dat werkt eigenlijk perfect. Het fijne hiervan is dat als een (oude) klant weer wat nieuws wil, we verder kunnen met het (verouderde) systeem, óf een merge kunnen doen zodat de klant gelijk een nieuwe versie van het systeem meekrijgt. Volledige flexibiliteit dus. Als we de middleware niet branchen, krijg je problemen als de klant later wat extra's wil laten maken

BCC schreef op dinsdag 19 mei 2009 @ 22:29:
[...]

Kijk anders eens naar Cake PHP, dat is het lichterlijk gehandicapte broertje van Ruby on Rails. Die hebben denk ik ook wel een variant van dit soort database migraties.

Eens kijken of de source wat is en of het te porten valt naar ZF. Migrations van RoR schijnt heel fijn te werken. Als dit de directe implementatie in php is, ga ik daar ook eens even induiken

Tja, het komt ook niet zo vaak voor. Maar er kunnen toch wel problemen komen als er ineens wel een wijziging komt. Verder wil ik ook meer gaan doen met versiebeheer.

My point exactly Daarom vind ik het ook bijzonder nuttig dat er een goede discussie over komt en er ervaringen gedeeld kunnen worden. Want kennelijk is het een ondergeschoven kindje maar wil iedereen er wel aan beginnen.

[...]

Houd je er wel rekening mee dat elk stuk maatwerk op je generieke kern een verdubbeling in je onderhoud betekend? (Wat Alain zei). Klantspecifieke database migraties zijn namelijk nog een heel stuk ingewikkelder dan generieke migraties.

Zeker als ik ook nog eens per module het wil gaan beheren Kennelijk iets wat redelijk onmogelijk is

[Boss]

Ik heb zelf goede ervaringen met DeZign, maar dat is alleen voor Windows. Op deze en deze pagina staat een aardig overzicht, misschien zit er iets tussen?

[Voutloos]

flashin schreef op dinsdag 19 mei 2009 @ 20:28:
Voor mijn projecten heb ik daar iig geen versiebeheer voor nodig, en mocht het echt een drastische wijziging zijn "along the way", dan maak ik wel eerst handmatig een dumpje.

Als je versiebeheer al hebt draaien, ben je imo gek als je niet desnoods enkel de structuur er in op slaat. Kleine moeite en het kan verrekte handig zijn. Nu weet jij bijvoorbeeld niet op basis van welke code verandering een db verandering plaatsgevonden heeft, of wat voor db je neer moet zetten als je een oudere versie wil deployen, of een oudere versie lokaal moet testen ivm een bugreport.

[Janoz]

flashin schreef op dinsdag 19 mei 2009 @ 20:28:
Waarom begin je met een fout database design?

Software is nooit af. Zelfs al zou je het utopische database model te pakken hebben, bij versie 3.x kunnen daar best nog wel wijzigingen in komen.

Uiteraard heb je veranderingen maar dit is, wanneer je je requirements goed bepaalt, vaak niet zo cruciaal.

Al ergens begin deze eeuw is toch wel consensus ontstaan dat de waterval methode nu niet echt de meest werkbare manier van software ontwikkeling is.

Voor mijn projecten heb ik daar iig geen versiebeheer voor nodig, en mocht het echt een drastische wijziging zijn "along the way", dan maak ik wel eerst handmatig een dumpje.

Versiebeheer is zoveel meer dan enkel een backupje bijhouden.

[Moraelyn]

Ik kwam laatst de volgende link(s) tegen, maar heb het gisteren pas gelezen. Daarna zag ik dit topic. Misschien interessant voor de discussie:

Three rules for database work
The baseline
Change scripts
Views, Stored procedures and the like

[Janoz]

Ik heb even vluchtig de blogs doorgekeken en volgens mij wordt daar precies de manier beschreven die werd toegepast op een groot onderhoudsproject waar ik een tijd bij meegedraaid heb. Het is inderdaad een erg robuuste manier van werken. Vooral het ontwikkelen van de change scripts zorgt ervoor dat je goed nadenkt over de implicaties.

Voor de discussie is het trouwens wel handig wanneer jij (of iemand anders) even een korte sammenvatting neerzet van wat er in de blogs besproken wordt (al was het maar een paar puntjes)

Tot slot kan ik iedereen die aan het nadenken is over dit onderwerp sterk aanraden de bovenstaande blogposts door te nemen!

[ Voor 10% gewijzigd door Janoz op 20-05-2009 12:14 ]

[BCC]

Ik vind de Blog wel erg open deuren intrappen, en als het nieuw voor je is moet je denk ik eerst maar eens een goed boek over databases development lezen. Wat ik trouwens nog mis is naming conventions voor tabellen en velden in de tabellen.

[Bryan Tong Minh]

In het geval van MySQL lijkt het bijhouden van binlogs een optie. Binlogs worden normaal gesproken gebruikt om slaves up to date met een master te houden. Wat je zou kunnen doen is op een bepaald moment een database dump maken en vanaf dat moment binlogs bijhouden. Je kunt vervolgens je database naar een bepaalde datum reverten door je dump te herimporteren en je binlog tot een bepaald moment te replayen.

Ok, misschien een beetje omslachtig.

[BCC]

Daarnaast wil je migraties aansturen op applicatie niveau ipv database niveau.

[creator1988]

Wij gebruiken een aparte database map in onze repositories, met daarin alle sql scripts voor de database. Mocht er voor een nieuwe release een databasewijziging nodig zijn, dan dient hier het .sql script van de SP/tabel/view/etc. aangepast te worden. De databasewijzigingen worden op de testomgevingen automatisch uitgerold per repo / omgeving (branches, trunk en de release-branches). Er zitten uiteraard wel altijd de checks in die bekijken of het object al bestaat, etc. maar dat lijkt me logisch.

Onze beheerpartij laat vervolgens op acceptatie (en later op productie) ook gewoon de scripts uitrollen. Mochten ze een rollback willen doen, dan draaien ze gewoon een backup terug.

Voordeel is dat we op elke lege database gewoon de scripts kunnen laten uitrollen in volgorde, en we dan weer de juiste indeling hebben. Bovendien toepasbaar op elke oude versie van de databases.

Door het in SVN te houden, ook automatische uitrol op de testomgevingen intern en extern mogelijk.

[BCC]

Dit is exact wat Ruby On Rails. Merb en Cake PHP standaard in huis hebben voor Migrations.

[Woy]

Ik heb hier in het verleden ook eens een topic over geopend: Versie beheer databases

[Remus]

Bij mijn vorige werkgever werd schema-evolutie gedaan door middel van een (zelf ontwikkelde) DAO/ORM laag. Deze laag kan zowel database-specifieke DML als DDL genereren. De structuur veranderingen werd dan ook semi-OO geprogrammeerd.
Hiervoor werd in de database het versienummer van het schema in de database bijgehouden. Veranderingen aan de structuur voor een feature (of soms meerdere) worden in één of meerdere opeenvolgende versienummers uitgevoerd. Bij het opstarten van het programma wordt 1) het versienummer gecontroleerd, 2) indien nodig de database geupgrade volgens de stappen en 3) een in memory structuur van de database opgebouwd aan de hand van de database-structuur (die weer gebruikt wordt voor het genereren van DML).

Voordelen: database-structuur staat gedefinieerd in de broncode (en dus automatisch in sourcecontrol), er kan database-onafhankelijk gewerkt worden

Nadelen: een proprietary structuur 'taal', DBA's die zelf zaken als indices weggooien of toevoegen waardoor de schema-evolutie soms kan falen.

[eghie]

Ik heb wel eens MySQLdiff gebruikt, om achteraf MySQL databases te updaten.

Nu gebruik ik een .sql bestand waar de DDL van de database in zit. Ik kijk dan naar welke revisie nummer er op het moment draait en doe dan een diff van dat revisienr met de meest recente en kijk wat er veranderd is. Dan bouw ik dat om naar ALTER TABLE queries, als een update bestand. Het werkt wel, maar is niet heel efficiënt.

Ik ga ook eens kijken naar http://www.liquibase.org/.

Wordt er hier trouwens ook rekening gehouden met de data in de database, dus niet alleen de structuur? Stel iemand heeft het niet helemaal goed begrepen en heeft het volgende zo geregeld:

code:

Gebruikers
------------------------------
id
naam

Groepen
------------------------------
id
naam
gebruikers

Met de volgende data:

SQL:

INSERT INTO Gebruikers (id, naam) VALUES (1, 'jan');
INSERT INTO Gebruikers (id, naam) VALUES (2, 'piet');
INSERT INTO Gebruikers (id, naam) VALUES (3, 'klaas');

INSERT INTO Groepen (id, naam, gebruikers) VALUES (1, 'Administrators', '1');
INSERT INTO Groepen (id, naam, gebruikers) VALUES (2, 'Gebruikers', '1,2,3');
INSERT INTO Groepen (id, naam, gebruikers) VALUES (3, 'Luie figuren', '2,3');

En je wilt die comma gescheiden gebruikers eruit slopen en dat in een koppel tabel gieten. Dan ben je niet helemaal meer op DDL niveau bezig, maar ook op data niveau. Hoe pak je dat aan met versie beheer?

Mijn bovenstaande methode, met vergelijken van structuur, werkt daar niet zo goed mee. Dus moet ik voor dit soort zaken een aparte update-oud-nieuw.sql bijhouden. Maar ik kan me voorstellen dat je dit ook via de update methode moet kunnen regelen.

[mithras]

Dat is ook vaak het probleem van database versioning software. Ze zien een kolom die er nu niet meer hoort te zijn, en geen kolom waar die er wel hoort te zijn. Het zou natuurlijk kunnen dat zo'n kolom gerenamed is, maar vaak kan je dat niet aangeven. De oude wordt weggegooid en een nieuwe aangemaakt: data verloren.

In Liquibase is dit trouwens wel mogelijk. Wel ideaal want zo behoud je de data. Maar imho mag Liquibase nog wat meer uitgroeien tot een volwassen systeem.

[ Voor 7% gewijzigd door mithras op 01-06-2009 10:08 ]

[BCC]

eghie schreef op maandag 01 juni 2009 @ 08:41:
Wordt er hier trouwens ook rekening gehouden met de data in de database, dus niet alleen de structuur?

Daarom wil je dus je database migraties altijd vanuit je applicatie laag aansturen. Zo kun je je data migraties namelijk eenvoudig regelen. Zaken als Liquibase doen inderdaad niet veel meer dan kolom er bij of eraf.

Rails migrations zijn koning

Ruby:

class AddBirthDateToPerson < ActiveRecord::Migration
  def self.up
    add_column :people, :birth_date, :date, :default => nil
    add_index :people, :birth_date
  
    Person.all do |person|
      person.fetch_birth_date_from_payroll_webservice
      person.save! if person.changed?
    end
  end

  def self.down
    remove_index :people, :birth_date
    remove_column :people, :birth_date
  end
end

Hey, de ruby syntax highlighter mist.

[ Voor 124% gewijzigd door BCC op 01-06-2009 22:53 ]

[Kalentum]

Ik ben ook op zoek naar een oplossing voor database migraties. Ik zit een beetje met het probleem dat min of meer grote functionaliteitswijzigingen in aparte branches worden ontwikkeld. Deze worden niet altijd lineair opgeleverd. Het kan best zijn dat een database change in branche A pas doorgevoerd moet worden als er ondertussen vanuit andere (latere) branches al andere wijzigingen zijn geweest. Het kan dan zijn de wijziging in branche A niet meer werkt of overbodig is geworden.

Een database migratie tool als Rails migrations werkt met versies. Dus branch A kan databasechange nr. 20 opleveren, branche B kan databasechange nr. 21 opleveren. Stel nu dat branche B eerst in productie komt en het database schema dus van van versie 19 naar 21 gaat en daarna komt branche A in productie. Hoe ga je daarmee om, bijvoorbeeld in combinatie met Rails migrations? Hoe weet je dan dat je ook nog change script 20 moet uitvoeren?

[BCC]

De nieuwe rails migration tool houdt dit bij door niet met versie nummers maar met timestamps te werken waarop de change gebouwd is. Bij een migratie wordt er gekeken of er migraties missen en als dit het geval is worden die uitgevoerd. Dit lost niet alles op natuurlijk (als je bijvoorbeeld migraties hebt die van oudere migraties afhankelijk zijn), maar wel 99% van je gevallen.

[Kalentum]

waar houdt rails migrations dat bij? Database of een file ofzo?

[BCC]

In de database dit een schema_migrations tabel, waarin de gedraaide migraties bijgehouden worden.

code:

sqlite> select * from schema_migrations;
20080714182750
20080714182752
20080714191818
20080715194957
20080903213158
20090102133017
20090102135348
20090102135845
20090102140508
20090102141041
20090102151406
20090522132600
20090522132700
20090527185256
20090527185341
sqlite>

De migrations zelf staan natuurlijk gewoon in de code repository:

code:

ls db/migrate/
20080714182750_create_accounts.rb
20080903213158_create_people.rb
20090102133017_add_birth_date_to_person.rb
...

[ Voor 84% gewijzigd door BCC op 03-06-2009 18:09 ]