Jochem Maas wrote:
lets forget that updating SQL schemas on massive DBs will likely take so much time that you will have to plan in downtime on the systems involved ... that's clearly out of the scope of this question.
Yes, this was part of the problem (and reason for my original post). At the moment I'm dealing with a 2GB SQL database, with hundreds of modifications per minute. Rolling out new features always requires that we take the site down anyway, just so we can stablise the changes coming in and back-up the database.
But this is more disaster recovery than version control, and doesn't get around a problem such as: running with a site upgrade (which expands an existing set of tables), taking new valid data from users into that new schema, plus into older un-touched tables, then needing to rollback for whatever reason - we're left with a horrendous 'merge' issue.
I'm surprised (or rather, I'm unaware of) there is no native MySQL solution for this situation. Perhaps that's left to the bigger boys? Or maybe it's the main 'weak area' of most web developers :)
- maybe that brainfart inspires somewhat, then again maybe you'll pass out fom the smell :-)
It did actually. I'm thinking that perhaps I tag all data with the *version* of the site in which it was created. And tag schema updates in a similar way as you suggested.
Still.. am amazed nothing more 'standard' exists. Cheers, Rich -- Zend Certified Engineer http://www.corephp.co.uk "Never trust a computer you can't throw out of a window" -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
