2 ms·
On the other hand, a reluctance to do schema changes often just leads to a de facto schemaless system if new concepts start getting hacked into generic fields i
by saltcured 3y ago
On the other hand, a reluctance to do schema changes often just leads to a de facto schemaless system if new concepts start getting hacked into generic fields instead of properly modeled.
When you make schema evolution really easy to do with no downtime, you can also start doing phased deployments where you think in terms of backwards-compatibility. First you add some new/optional parts to the schema. Then you update the applications to use it, where the application has to tolerate data with or without the new bits.
Eventually, you might convert something from optional to required, first for new data entry and later as a conversion of existing data, where that makes sense. Then finally you might deprecate the application ability to handle the old missing bits, and remove that from your code maintenance problems.
- _a_a_a_ 3y agoMaybe proper releases, running on different machines, might be a better option most of the time.