How do you handle Database Configuration Management?

Application Code can simply be recompiled completely when a new build is done. However, recompiling the database involves dropping and re-creating tables. This can't be done once you go live.

Now one method is to use upgrade scripts. So you have one initial release of the database and simply run upgrade scripts to increment to a new release. This can be a problem if you have to stand up a new schema. After some time you can have alot of upgrades to run. This can be management with code, but this is run serially and could take a significant amount of time to take a new database to the same level.

Another option is a mix-of upgrades and being able to re-create your database tables/code, etc... to the same level. So you have an upgrade directory to run upgrades, but you also keep DDL scripts so you can code and a script to build this. The problem with this is that you are alot of times keeping two versions of the code and to really run a test you have to test and maintain both copies.

Now another option is to use a repository like designer or Erwin. We don't have those tools.

So how do you handle CM for your projects? I have always found this to be pretty time consuming. Especially if you have multiple parallel developments going on.

Version 1.1 is going out friday
One team is working on version 1.2 which is due out in a month Another team is working on a different module which is in version 1.3 which goes out after that

You then have to "merge" your code. You can run into a problem where 1.1 is in System Test(QA in the private sector) and then it "fails", but version 1.2 is in development and developers are working off of the bugged version of 1.1.

btw, we are using Subversion. I have used PVCS and Rational in the past and have found those to be more robust tools, however, they also tend to require administrators to keep them running.

--
http://www.freelists.org/webpage/oracle-l