Database versioning part 1

Versioning databases is one of those ongoing problems that has no one-size-fits-all solution. There are 2 solutions I have developed and used successfully.

The general process I use each time is:

1. Record the database version number in the database
2. Define the expected db version the application
   
3. Keep a master db for comparison
   
4. Only make one set of changes at a time
5. Automate differencing as much as possible
   
6. Unit test, test and test again. The tests should fail the moment a table is modified.
   

Situation 1
MSDE (= SQL server) database
8 developers (pair programming)
C# application

Every developer had 2 databases, Unit Test db and Application Test DB (UnitDb and AppDb from now on). With msde (now sql express) there are no licensing costs to worry about.
There was also a Master database stored on a central server that served as the canonical reference.

The database version number was stored in a view ('select xx as VersionNumber).

To make database changes, the following process was used:

1. Check out the latest version of the app
2. Increase the version number in the application
   
3. Make and test DB changes. Usually this was done in UnitDB. AppDb was kept synchronised using SQL Compare
   
4. Update the version number in UnitDB
5. Generate an update script using Sql Compare. Scripts were named UpgradeXXX.sql where XXX is the version that was being upgraded from.
   
6. Generate a CreateDatabase.sql script (for shipping with the app) and a CreateDatabaseXXX.sql (for unit tests only) script. In this case XXX is the version that will be created. The 2 scripts are the same except for the name.
   
7. If necessary (rarely) append further queries to the scripts. E.g. to set the values of new fields, or to add new data rows.
   
8. Update unit tests to suit the new db
9. Check in changes
   

When the application is run, it goes through the following process

1. If no database is found, then run CreateDatabase.sql
2. Get the current version number from the database
3. If it is less than the expected version number then
   run UpgradeXXX.sql and go to 2

When the unit tests are run, the first step is to upgrade UnitDb to the current version using the same process as the main application. That means that other peoples changes are automatically applied. The unit tests included:

• Make sure the current version is correct
• Make sure that every table and every field exist (this doesn't always need to be explicit as the persistence unit tests should pick up any problems here).
• Create a new blank database (for a number of different versions) and work though the upgrade process to make sure the final database is correct.
  

The secret weapon in all this was sql compare which makes generating the scripts quite straight forward.
Also the upgrade scripts can do more than one set of version changes. ie Upgrade001.sql could upgrade the version to v10 so that scripts 002 - 009 don't need to be run.

Situation 2 (delphi and dbisam) will follow in a later post.

Links
Sql Compare