The full DB dump might be good if it is also accompanied by update scripts for both up and down. This way an existing system can just have their tables updated, but a new system can have a clean install. However, this still doesn't solve the problem of the 2 devs committing differing changes to the database – there will always be, as you say, a winner and a loser.

The best solution is probably the non-tech solution! (Which pains me to say!) where one dev is the DBA and all changes can go through them. This could be coupled with an agile mentality of having daily meetings to discuss any structural changes needed the the database and why.

Thanks for your thought provoking comment.

Revision control systems are based on the premise that we're mostly dealing with text files, and when there's a conflict we can diff and merge. Obviously this doesn't work with databases.

One can keep a record of all changes as (an) SQL file(s), and when updating, import the latest changes.

Problems are (apart from the possibility of forgetting to record a
statement) that:

– The statements aren't easily automatically reversible when you need to do a revert. That would take a sophisticated SQL parser (that would also be DB server specific)

- Some transactions aren't simply reversible (DELETE, DROP etc)

- It's little help when there's a conflict – i.e. two devs commit 2 very different changes to the database. The accompanying code (at least at the model level) is also too tied to the underlying DB structure.

One solution (though inelegant and wasteful) is to force (or better script) that just prior to each commit, a full DB dump is made. When updating, the existing local DB is completely replaced by the dump. Still doesn't help much with conflicts with mutually exclusive DB structure changes – there then would be a “winner” and a “loser”.

Despite my fondness for things agile and extreme, I actually think it's often good in the long-term to have the core DB structure made concrete before starting coding. It's always a major PITA when core tables need to change half-way through a project. (Extra tables aren't usually a problem)

One non-technical solution is to have one dev designated as the DBA, and all changes to structure and required records would go atomically through them.