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@proximity.com.au
Proximity Pty Ltd http://www.proximity.com.au/