![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
The database schema, and the 'reference data' in it (eg "a dictionary of all customer types possible"), needs to be versioned, just like code.
For every modification to the database schema or the reference data, create a separate file containing a script with the changes (the file is 'self-sufficient', eg not dependent on any other code you wrote, so that if you change other parts of your code, you can still run it and it will still have the same effect on the database; some ways of accomplishing this are (a) use only raw SQL, not framework-mediated code, in the script, or (b) defining locally in the script any code you wrote that the framework will call or look at during its execution, eg locally defining relevant classes).
After one of these database modification script files has been deployed to production, it becomes immutable (eg you don't change it anymore; instead you write new SQL modification script files that run after it).
The name of these script files should not just be integers, but names (this makes it easier to merge branches).
The database itself has a table that identifies which script files have been applied to it.
Every developer in the team has their own database instance.
If the number of modifications gets too large to run all of them quickly during development, create a snapshot of a database containing only the schema and the reference data, and then only apply modifications after that.
Links:
