Version control of database schema

After a very painful merge process, I come up with these practice.
Maybe not THE best practice, but at least these will eliminate most problems.
And NO, these practice only applies to database WITHOUT foreign keys and other dependency between objects.
By the way, I only worked with DB2.

1. One file per main object. Match the name of file and the object within. The idea is to follow the java object law.
2. If migrating from files with many objects, eliminate all diff noise before you do teardown.
3. Keep only ddl's, the final state of an object creating script. You also need a one-fits-all script to submit them all at one push.
4. Keep schema alteration SQL's in another folder, only in release branch or trunk per release. Version the whole folder, which means keep only those for the migration from the last release.

For anyone needs foreign keys and other dependency between objects, try to hack the object naming and let them work through your deploy script.

I hope these will work. Please leave comments!

Go! Go! Destroy! PPCC!

BiS rules!

Nozoshyan is so cute.