Så mange mennesker forsøger at gøre denne slags ting (forskellige skemaer). Min mening er
- Kildekoden går ind i et versionskontrolværktøj (Subversion, CSV, GIT, Perforce ...). Behandl det som om det var Java- eller C-kode, det er virkelig ikke anderledes. Du bør have en installationsproces, der tjekker den ud og anvender den på databasen.
- DDL ER KILDEKODE. Det går også ind i versionskontrolværktøjet.
- Data er et gråt område - opslagstabeller burde måske være i et versionskontrolværktøj. Applikationsgenererede data burde bestemt ikke.
Den måde, jeg gør tingene på i disse dage, er at skabe migrationsscripts, der ligner Ruby on Rails-migreringer. Indsæt din DDL i scripts og kør dem for at flytte databasen mellem versioner. Gruppér ændringer for en udgivelse i en enkelt fil eller et sæt filer. Så har du et script, der flytter din applikation fra version x til version y.
En ting, jeg aldrig nogensinde gør længere (og jeg plejede at gøre det, indtil jeg lærte bedre) er at bruge et hvilket som helst GUI-værktøj til at oprette databaseobjekter i mit udviklingsmiljø. Skriv DDL-scripts fra dag 1 - du skal alligevel bruge dem til at fremme koden til test, produktion osv. Jeg har set så mange mennesker, der bruger GUI'erne til at skabe alle objekterne og når frigivelsestidspunktet er, der er en scrabble at forsøge at producere scripts til at oprette/migrere skemaet korrekt, som ofte ikke er testet og fejler!
Alle vil have deres egen præference for, hvordan man gør dette, men jeg har set meget af det gjort dårligt gennem årene, hvilket dannede mine meninger ovenfor.