One of the most important things any programmer needs to be taught is how to use version control. There's no getting around it; you could be the world's best hacker, but if you make one stupid little mistake without version control, that great, world-changing project of yours is scrap. And generally, most of us do use version control. For our code.

Unfortunately, the state of version control for databases lags far behind version control for practically everything else. Directly versioning the database files doesn't work; unless you take the database (and the application on top of it) offline to back it up every time you change the schema, you're prone to suffer sync issues. Another solution is to rebuild the database from scratch every time you change a table; up until this morning that's how it was for Taskerrific.

But I knew there was a better way, one that minimized mucking about with the database and provided a safe path for going between database revisions. While it's still not perfect, MigratorDotNet offers a nice way to version databases; by treating the schema as code, too.

It's not so simple as just changing some code and having that automatically turn into a bunch of ALTER TABLE commands, however. Instead, every time you change the database schema, you write a new class, which implements a Migration, the difference between two versions. Each migration class offers a function to move forward or backward through the database versions, like so:

This way, you can also roll back changes later on, perhaps after some development gone wrong. Now version control is simple; check in your migration classes, and whenever you need to update the database, check 'em out and run 'em!

MigratorDotNet was inspired by a part of Ruby on Rails called ActiveRecord Migrations, but the actual development, as far as I can tell, comes from a similar project as part of Castle. (But not, apparently, Castle's ActiveRecord project. Odd.) Thanks to its design, MigratorDotNet works with a variety of commonly used database engines; when your migrations are run, the project's framework automagically builds the SQL statements which modify your database and run them for you.

MigratorDotNet is currently in version 0.8.0, and based on activity on the project site, I'd estimate 0.9.0 coming out of the pipe within the next couple months at the latest. If you have application-critical databases lacking a solid version control system, I'd suggest taking a look at MigratorDotNet. Your actual project need not even be a .NET application to use it!