A problem faced by many development teams is how to manage structural change within a database and how to make sure all developers are working with the correct database structure during a project. A common technique for handling this is to use migrations.
Our current PHP framework uses rails-style migrations which are identified by a timestamp and contain an up/down function that encapsulate the change being made to the database. Other migration styles differ from this in a couple of ways. These are the most common ones:
- Instead of using a timestamp to identify migrations, an auto-incrementing integer is used. This isn't ideal when you have multiple developers on a team working on different migrations at the same time; two developers might have the same ID assigned to the migrations they're working on and will encounter a conflict when merging their code together. In the PHP world Akelos uses this method.
- Instead of using up/down methods, the complete schema is described and the framework computes the changes that need to be made. We have avoided using this style because it limits our ability to deploy migrations that might not actually change the schema. It also introduces (or increases) the risk of the schema change unintentionally. Symfony uses this idea.