- "You should never tie database migrations to application deploys or vice versa. By minimising dependencies you enable faster, easier and cleaner deployments."
- "Backward compatibility with older versions of a database schema is typically something to avoid, and hacking your Data Access Layer to support multiple schema versions feels like a design smell."
- "Forward compatibility is tricky because you have old code running that now need to handle a new use-case it was not designed to handle when it was initially written."
3. single data access service
All data should be persisted and loaded using a single service. This service should handle database schema changes and deliver data according the version of the client.
- Backward compatibility: use default value in case the clients have not been deployed yet and do not send the new field.
- Forward compatibility: Old service versions have to ignore unknown fields and parameters, the services are resilient to API extension.
- Change current architecture
- Time and cost
- Every change you make must be backward compatible with the rest of the system.
- A cleaner solution is to ensure that your code is always running against the version of the schema which that code has been written for.
- Store every change in the database schema
- SQL script files for downgrade and upgrade
- Every SQL script file must be immutable after it is deployed to production or staging environment.
- All changes in the database’s schema and reference data have to be applied through the scripts. Neither of them can be applied manually.