> "CP" == Collin Peters <[EMAIL PROTECTED]> writes:
CP> I have thought of the following situations:
CP> -Simply track all the changes you made to the development database and
CP> make the same changes to the release database
CP> -Back up the release database... overwrite it with the developmen
Best practices for migrating a development
database
Beside version controlled schema files we have a guy who writes
migration scripts based on the old schema and the new (development)
schema (frozen e.g. by branching in CVS).
Usually there are 3 steps involved:
- a pre-migration script, which prepare
Beside version controlled schema files we have a guy who writes
migration scripts based on the old schema and the new (development)
schema (frozen e.g. by branching in CVS).
Usually there are 3 steps involved:
- a pre-migration script, which prepares the data base for the new
schema, by adding the
One thing I used to do (and I won't necessarily claim it as a best
practice) was to maintain my entire data model (tables, functions,
indexes, sequences) as SQL (plus postgres extensions) CREATE statements
in text files that were version controlled (via CVS). I had an entire
set of utilities th
I have searched the Internet... but haven't found much relating to this.
I am wondering on what the best practices are for migrating a
developmemnt database to a release database. Here is the simplest
example of my situation (real world would be more complex).
Say you have two versions of your
