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
