Database Upgrade Methodology

Question

In general, the schema of a database will change over time. Between builds, zero to many schema changes can occur. What is a "best practice" for capturing these changes?

For example, let's say 2 developers are working on a project and using git for source control. They agree to have a build on Friday. Each go about their work, checking in changes with database migration scripts that update to the current schema. When person A gets person B's changes, how can they easily know which upgrade scripts to run? When a person is looking at a database on a server, how can they know which version they are on? If the database captures the version number, that means that on Friday, one of the people on the team had to say to everyone else "Ok, everyone check in, then I am going to write a script that updates the version number to the next version and check it in."

Is there a standard way to approach this? Thanks.

Answer 1

Consider writing one migration per database [structure] change, not per stable version of your system. Just like revisions of code: every change updates system and increments it's revision (not version).

Usually we store database revision (along with 'public' version) in a special table. Sometimes we store names of migration scripts that were applied to this database, but it's more complex solution. It's handy to inlude revision of database which would be after applying migration in the file name. Last line in migration script updates migration version in a special table.

To determine which migrations to apply to concrete developer's database, you just take all the migrations that have higher revision number than revision of database that is stored in a special table.