How do you manage databases in development, test, and production?

Question

I\'ve had a hard time trying to find good examples of how to manage database schemas and data between development, test, and production servers.

Here\'s our setup. E

Answer 1

Have a look at how Ruby on Rails does this.

First there are so called migration files, that basically transform database schema and data from version N to version N+1 (or in case of downgrading from version N+1 to N). Database has table which tells current version.

Test databases are always wiped clean before unit-tests and populated with fixed data from files.

Answer 2

For oracle database we use oracle-ddl2svn tools.

This tool automated next process

1. for every db scheme get scheme ddls
2. put it under version contol

changes between instances resolved manually

Answer 3

The book Refactoring Databases: Evolutionary Database Design might give you some ideas on how to manage the database. A short version is readable also at http://martinfowler.com/articles/evodb.html

In one PHP+MySQL project I've had the database revision number stored in the database, and when the program connects to the database, it will first check the revision. If the program requires a different revision, it will open a page for upgrading the database. Each upgrade is specified in PHP code, which will change the database schema and migrate all existing data.

Answer 4

You could also look at using a tool like SQL Compare to script the difference between various versions of a database, allowing you to quickly migrate between versions

Answer 5

This is something that I'm constantly unsatisfied with - our solution to this problem that is. For several years we maintained a separate change script for each release. This script would contain the deltas from the last production release. With each release of the application, the version number would increment, giving something like the following:

• dbChanges_1.sql
• dbChanges_2.sql
• ...
• dbChanges_n.sql

This worked well enough until we started maintaining two lines of development: Trunk/Mainline for new development, and a maintenance branch for bug fixes, short term enhancements, etc. Inevitably, the need arose to make changes to the schema in the branch. At this point, we already had dbChanges_n+1.sql in the Trunk, so we ended up going with a scheme like the following:

• dbChanges_n.1.sql
• dbChanges_n.2.sql
• ...
• dbChanges_n.3.sql

Again, this worked well enough, until we one day we looked up and saw 42 delta scripts in the mainline and 10 in the branch. ARGH!

These days we simply maintain one delta script and let SVN version it - i.e. we overwrite the script with each release. And we shy away from making schema changes in branches.

So, I'm not satisfied with this either. I really like the concept of migrations from Rails. I've become quite fascinated with LiquiBase. It supports the concept of incremental database refactorings. It's worth a look and I'll be looking at it in detail soon. Anybody have experience with it? I'd be very curious to hear about your results.

Answer 6

We are using command-line mysql-diff: it outputs a difference between two database schemas (from live DB or script) as ALTER script. mysql-diff is executed at application start, and if schema changed, it reports to developer. So developers do not need to write ALTERs manually, schema updates happen semi-automatically.