What are changes made to a database schema that is already in 4NF that would break applications?

Question

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?

Answer 1

Most changes are "breaking" if you aren't careful. Any change to code for example (you mentioned triggers). Any new or modified constraints, calculated columns etc.

You could even add a new index and effectively "break" your application because a query that used to run sub second now runs in seconds, minutes, even hours because the query plan has changed.

Assuming your code is written to always specifically name columns will probably make adding new columns reasonably safe and adding a table almost always is but you still probably want to test how each change to your database affects your application and it's performance.