Karsten Hilbert wrote:
My main concern, however, was whether the *approach* is sound, eg using a separate database name per release or IOW version. One way would be to use the database name "gnumed" regardless of release, another way would be to use "gnumedX_Y" for release X.Y. I wonder whether the latter approach has any drawbacks people might think of regarding release management etc.
Others have given you some of the advice I would have given. One more suggestion - does your database fit in just one "schema" in the gnumed database? If so, then an easy option would be to have all versions of your software use the same database, but each one has its own unique schema within that database. This gives you the same ease of reversion to a previous version, and gives you the added advantage that it's much easier to write the scripts that update from one version to another, since they can just operate within the same database, eg selecting data from one schema and inserting it into another. Your users would then drop old schemas on whatever basis they feel comfortable with.
What we do in practice is upgrade the database in situ when we upgrade the software. We use a schema version number to automatically determine what scripts to run - similar, I think to what Rick Levine was describing. However, we have no easy way to revert to an old version if required - so your plan will be better than ours in that regard.
Tim -- ----------------------------------------------- Tim Allen tim@xxxxxxxxxxxxxxxx Proximity Pty Ltd http://www.proximity.com.au/ ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
