For this question I consider applications select and use columns by name (so I am excluding use of select * as a breaking change).
Asked in a different way, is it the case that once a Database schema is in 4NF then any change that needs to be applied to it should only be an "additive" change and therefore not break any existing applications that use it?
For me I am discounting some obvious changes:
- Drop column (This change can be held back and only applied once all uses of the column are no longer active)
- Drop table (Same as drop column)
For me I am considering "additive" changes as non-breaking:
- Add column
- Add table
- Denormalisation (Add column + whatever triggers etc are required)
For me the "Refactoring" change that would break applications is to alter a columns datatype (e.g. Change from INTEGER to VARCHAR type)
What other changes can be made to a schema in 4NF that will break applications using that schema?
UPDATE: Currently we have:
- Changing the data type in a breaking way (INTEGER -> VARCHAR)
- Adding a constraint (or tightening an existing constraint)
Q: Are there any schema design changes that can take a design from 4NF into a different 4NF design?