Reg. datum: 31 oktober 2007
Berichten: 4
Reg. datum: 31 oktober 2007
Reg. datum: 31 oktober 2007
Berichten: 321
Reg. datum: 07 november 2002
Reg. datum: 07 november 2002
Zijn de databaseschema's niet in ASCII beschikbaar (als een .sql file)? Die kun je natuurlijk prima in SVN opslaan...
Dit zijn de sheets van een presentatie van een collega van mij.
http://innoveerjijmee.nl/.../id,46/Up-to-database.pdf
Zonder verhaal erbij is het misschien niet zo nuttig, maar de presentatie gaat precies over dit onderwerp.
Ik vind persoonlijk Liquibase een erg leuke tool.
http://innoveerjijmee.nl/.../id,46/Up-to-database.pdf
Zonder verhaal erbij is het misschien niet zo nuttig, maar de presentatie gaat precies over dit onderwerp.
Ik vind persoonlijk Liquibase een erg leuke tool.
Fat Pizza's pizza, they are big and they are cheezy
Wij gebruiken zelf sinds een tijdje DeZign for Databases van Datanamic. Je kan dan versies bijhouden van je datamodel, en eventueel ook de scripts laten genereren om in gebruik zijnde databases te converteren. Werkt met alle bekende DBMSsen samen.
Ze slaan zelf de data op in XML, dus evt kan je ook het versiebeheer gewoon in je eigen systeem doen.
Ze slaan zelf de data op in XML, dus evt kan je ook het versiebeheer gewoon in je eigen systeem doen.
The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.
Ik splits in de trunk meestal op in documentatie, database en sources.
In de directory database hou ik 3 dingen bij:
- Een actuele SQL structure dump van alle tabellen per database
- Een actuele SQL data dump van alle stamdata en (unit)testinstellingen
- SQL Migratiescriptjes waarin duidelijk staat [van revisie]-[naar revisie]
Door jezelf aan te wennen om ook een nieuwe structure dump te maken als door toegevoegde functionaliteit het databasemodel verandert, blijven je commits consistent.
Ik vind het makkelijk om bijvoorbeeld tussen mijn 1.0 tag en 1.1 tag de verschillen te bekijken in de structure file. Toegevoegde of verwijderde velden / tabellen zijn makkelijk te visualiseren. Zelfs al heb je geen migratiescripts gemaakt, dan is het nog prima leesbaar voor iemand met redelijke SQL kennis. Een handige tool om differences te bekijken vind ik WebSVN, aangezien die lekker laagdrempelig is (geen svn client, diff viewer nodig) en omdat deze op een goede manier met kleuren visualiseert wat er is veranderd.
Uiteraard is dit proces ook naar believen te automatiseren. Zo heb ik gewerkt in omgevingen waarin nightly builds werden gedaan. Het is dan een koud kunstje om even een mysqlexport scriptje ertussen te hangen om de actuele structuur te overschrijven.
In de directory database hou ik 3 dingen bij:
- Een actuele SQL structure dump van alle tabellen per database
- Een actuele SQL data dump van alle stamdata en (unit)testinstellingen
- SQL Migratiescriptjes waarin duidelijk staat [van revisie]-[naar revisie]
Door jezelf aan te wennen om ook een nieuwe structure dump te maken als door toegevoegde functionaliteit het databasemodel verandert, blijven je commits consistent.
Ik vind het makkelijk om bijvoorbeeld tussen mijn 1.0 tag en 1.1 tag de verschillen te bekijken in de structure file. Toegevoegde of verwijderde velden / tabellen zijn makkelijk te visualiseren. Zelfs al heb je geen migratiescripts gemaakt, dan is het nog prima leesbaar voor iemand met redelijke SQL kennis. Een handige tool om differences te bekijken vind ik WebSVN, aangezien die lekker laagdrempelig is (geen svn client, diff viewer nodig) en omdat deze op een goede manier met kleuren visualiseert wat er is veranderd.
Uiteraard is dit proces ook naar believen te automatiseren. Zo heb ik gewerkt in omgevingen waarin nightly builds werden gedaan. Het is dan een koud kunstje om even een mysqlexport scriptje ertussen te hangen om de actuele structuur te overschrijven.
This message was posted using 100% recycled electrons
Pagina: 1