3 ms·
I believe (in practice if not theory) it is common to handle db schema updates separately and to run both systems off the same database. This way the data only
by robinwarren 11y ago
I believe (in practice if not theory) it is common to handle db schema updates separately and to run both systems off the same database. This way the data only lives in one location but you get to run two slightly different app servers/frontends on top of it. You are then more careful with database changes. This sounds like a pain in the arse but a lot of people seem to be able to run with it without it causing a lot of additional overhead having to schedule your db changes to go out before your dependant code changes.
- hartror 11y agoYeah this is how you do it. You can also use feature toggles to help manage this. http://martinfowler.com/bliki/FeatureToggle.html http://martinfowler.com/bliki/FeatureToggle.html
- neilellis 11y agoYep agree, also keep the database schema a little soft - i.e. tolerant of minor changes. ( an example for SQL databases of this is having an 'additional info' field/table which has no value for indexing but contains additional captured info.)
- anton-107 11y agoSo does this effectively mean - only create tables and add columns in your db schema migrations (no updating and removing)?
- lmm 11y agoYou can remove but you update the application to not read from the removed column (and test this in a test environment) first. "Updating" is best done by adding a new column, writing to the new column in parallel, back-populating it, reading from the new column, and then dropping the old column. It's a bit cumbersome but it works and it's safe.