Hello,
> Could somebody explain me, or point me to a resource where I can find
> out what is the recommended practice when a live db needs to be replaced
> with a new version of it that has a slightly different structure?
>
> What do you usually do in a situation like this?
That's a big problem for us too. We develop web application in "always
beta" regime, having very short one-week release cycle. It is
practically impossible to foresee all business requirements that
affect database structure, so almost every release we need to change
it on the live server. However, it's critically important to plan the
DB structure properly anyway, so that you will change it only slightly
in future.
Some time ago I did not manage to find information on how to update
both application and database without any interruption of the clients.
I can easily update my application without any losses within a
transaction (`mv` command), I can easily do the same with PostgreSQL,
but how to *coordinate* both changes? What if my working application
introduces some logical inconsistency when I updated DB structure but
not yet updated application?
So we could not find a correct solution. IMHO, the only good practices
are to test transition intensively in development enviroinment to
smooth it, minimize database changes and minimize release duration.
Now every week we write release plans trying to think it over in
details, then stop application showing some fun message to users and
do quickly what we planned in advance. It takes 2-3 minutes to
complete everything, but I would like to avoid it...
Sincerely,
Ivan Zolotukhin