4 ms·
The problem is pretty universally solved: 1. Use some sort of schema migration tool to keep track of and version all changes you've made to the database since
by Pewpewarrows 15y ago
The problem is pretty universally solved:
1. Use some sort of schema migration tool to keep track of and version all changes you've made to the database since your very first commit.
2. Never do a backwards-incompatible schema change. Never. Time and time again these are the ones that will completely bite you in the ass when the day comes that you broke production with a deployment and desperately need the old version back up and running. You're going to end up losing data and shit will hit the fan. It doesn't take much code-wise to support the old scheme, and it will ensure that you have zero downtime while rolling out your updates.
3. Never delete data. The only exception being if some user-submitted content violates a law, like child pornography. In which case, it shouldn't be part of your migration/update process to begin with. Just use deleted flags / boolean fields. Note in your code when certain fields are no longer used anymore because they're only there to support legacy versions.
- jpluscplusm 15y agoI totally get all these points; is there any literature I can point our devs towards to convince them (a) #2 + #3 don't leave any corner cases and (b) they really should take the time to do it (ultimately so I can put an automation solution around the the DB)?
- cdavid 15y agoI am pretty much a beginner in database handling, what would you suggest for 1 ? Concerning 2: how do handle schema fixes (example: at my previous job, the tables were very badly designed, and the application+schema combination prone to frequent race conditions). What to do in this case ? As for 3, I already came to this conclusion on my own, so I was not completely on the wrong track :)
- quicksilver03 15y agoI've used DbDeploy and Mybatis Migrations with good success, they're written in Java but they've also been handy in PHP projects.