[Alg] Versiebeheer database

[Orphix]

Hallo,

Ik werk al een tijdje met SVN als source-control programma. Dit werkt voor mij zeer goed. Voor de broncode bestanden dan. Ik ontwikkel nu asp.net sites met een ms-sql als databaseserver. Vooral tijdens de ontwikkelfase kan het databaseschema nogal eens veranderen.

Ik heb nog niet echt een goede manier gevonden om dit consequent, en liefst automatisch, te integreren in mijn versiebeheer. Op dit moment werkt ik met een soort nul-versie schema van de database die ik ooit heb gemaakt. Vanaf dit punt sla ik alle wijzigingen dmv change-scripts op in afzonderlijke bestanden. Dit is enigszins werkbaar, maar je loopt al snel op dependency-conflicts. En natuurlijk moet je heel consequent en precies te werk gaan, als je een script vergeet kan alles in de soep lopen.

Nou zag ik dat je (3rd party) software hebt die twee sql databases met elkaar kunnen vergelijken en automatisch een change script kunnen genereren. Hebben jullie hier ervaring mee en werkt dit goed?

Algemener ben ik benieuwd naar jullie strategie om hier mee om te gaan. Dus ook: sla je je revision nummer op in de database? Of loopt site/applicatie en database revision altijd synchroon? Wordt je schema automatisch gegenereerd bij het committen van een nieuwe revisie? Gebruik je een buildscript voor het updaten van de database, of gaat dit handmatig?

[whoami]

Orphix schreef op zondag 06 februari 2005 @ 14:30:
Nou zag ik dat je (3rd party) software hebt die twee sql databases met elkaar kunnen vergelijken en automatisch een change script kunnen genereren. Hebben jullie hier ervaring mee en werkt dit goed?

Wij gebruiken RedGate SQL Compare (ik denk dat je op dit programma doelt).

Het volledige database schema staat in Visio; wijzigingen worden dus in dat schema aangebracht.
In het geval van wijzigingen aan de structuur, gaan we dat schema dus aanpassen, en maken we aan de hand van dat schema een nieuwe DB.
Die vergelijken we dan met Redgate met de vorige versie van onze DB, en we laten een script genereren die ervoor zorgt dat de vorige versie gelijk kan gezet worden met de nieuwe versie.
Dat script slaan we op.

Om een DB te creeëren gebruiken we een (eigen gebakken) tooltje die de DB maakt vanaf een bepaalde 'baseline', en dan alle patches (scripts die door redgate gegeneerd werden) gaat gaan toepassen.
Ook het updaten van een bestaande DB verloopt via deze tool.

Iedere patch zorgt er ook voor dat er een versie-nr in de DB wordt bijgehouden.

[FendtVario]

Om de database van up to date te houden heb ik een kleine util geschreven dat van een bestaande database een XML maakt met de structuur en deze wordt vervolgens met een update meegeleverd. Een ander deel van het programma vergelijkt de XML met de database (velden, data typen, veldlengtes, indexen) en werkt vervolgens de database bij. Als er een keer een update overgeslagen wordt heeft is dat ook niet zo erg. Ik kan echter geen velden en/of tabellen verwijderen, technisch is dat natuurlijk wel mogelijk, maar we hebben toen besloten om dat niet te maken.

[Orphix]

Ik merk dus dat elk bedrijf weer zijn eigen in-house tools gebruikt. Ik mag hieruit opmaken dat er nog niet echt standaarden zijn? Of veelgebruikte toepassingen om dit te bewerkstelligen? (zoals cvs of svn)

[JaQ]

Orphix schreef op maandag 07 februari 2005 @ 19:09:
Ik merk dus dat elk bedrijf weer zijn eigen in-house tools gebruikt. Ik mag hieruit opmaken dat er nog niet echt standaarden zijn? Of veelgebruikte toepassingen om dit te bewerkstelligen? (zoals cvs of svn)

Binnen Oracle Designer bestaat zoiets als SCM. (als ik me niet vergis heet de versioning van designer zo). Deze verzorgt versiebeheer. Oracle Designer kan echter veel meer dan alleen een database ontwerp vastleggen.

[djc]

Je zou iets kunnen doen met een Subversion-hook-script dat iets als SHOW CREATE TABLE (dat is MySQL, ik weet niet in hoeverre MSSQL dat ook ondersteunt) uit de database trekt en dat commit in een bestandje (in een aparte commit, most likely). Weet niet precies hoe je dat goed kunt regelen, waarschijnlijk kan je het het best post-commit doen, en dan op een of andere manier eerst een svn up doen in een directory, daarna het laatste database-schema eruit trekken en committen.

Makkelijker is het misschien om gewoon een snelkoppeling te maken naar een scriptje dat de database-beschrijving uit de db trekt, in een bestandje pleurt en dat commit.

[raptorix]

Sql Server kan je direct koppelen aan sourcesave, nooit gedaan, maar het is wel mogelijk.

[sopsop]

Bij mijn vorige werk had ik het change beheer van een SQLServer in beheer. Het probleem daarbij was dat er veel releases en bugfixes voor de software uit werden gebracht en deze bij veel klanten moesten worden doorgevoerd. Het kon dus voorkomen dat klanten een upgrade van een aantal versies moesten krijgen.

Dat hebben wij als volgt opgelost:

In VB (maar da's verder niet zo relevant) werd er per release/bugfix en per database (we hadden er een aantal) een VB functie aangemaakt. In zo'n functie werd een stored procedure aangemaakt die de database bijwerkte tot dat niveau. Vervolgens werd het versienummer van de database opgehoogd. Dit alles in een transactie, zodat er ook bij fouten een roll-back gedaan kon worden.

Bij het uitvoeren van de applicatie wordt iedere upgrade-functie aangeroepen, waarbij er eerst wordt gecheckt of de update op basis van het huidige versienummer uitgevoerd moet worden, zo niet dan wordt de functie zonder actie weer verlaten. Dit werkte in ons geval fenomenaal. Even zorgen dat de ini-file van de upgrade tool de juiste databaseconnectiesettings had en het tooltje uitvoeren. Geen losse scripts die uitgevoerd moeten worden, gewoon draaien en klaar.
Om een nieuwe functie voor de upgrade tool te maken had ik nog een tooltje gemaakt waarin je de database opgaf, de versie van de database die na uitvoering van het script ontstaat. Dat tooltje genereerde vervolgens de VB functie die in de applicatie geplakt kon worden.