Database Versioning: The ignored aspect of version control.

Version control is an important aspect of writing code. From the initial check-in to the final build, it is crucial to keep track of every change that is made to the code. Like stacking blocks of legos, you will find what started with a single brick evolving into a city. Databases, however are often ignored from version control. If you are lucky you use some form of ORM to connect to your database like Active Record. This will handle database migrations for you and provide database version control to some degree. However for legacy projects you are out of luck. More often than not I have seen the code managed very carefully with awesome branch and merge strategies implemented. Whereas all the database scripts simply dumped in a directly called SQL. Or if you are lucky there will be sub directories with stored procedures, tables and functions in their own directories.

By versioning the database you get the ability to apply and rollback changes or "deltas" to your database. The simplest way to do this is , as mentioned above, is to use an ORM. However if you have an already established database and code and switching to ORM is not an option then there are other ways in which you can do this. There are products available on market that can help you version you database. For SQL Server Red Gate offers SQL Source Control that integrates with leading VCS. For MySQL there is dbv.php. Then there is software like Liquibase which is feature rich, free and supports a lot of databases.

And when all else fails grab a scripting language of your choice and automate it yourself. With a mix of automation and policies you can bring any database under version control.

You can read more how how to achieve Database Versioning here Database Versioning: The ignored aspect of version control.