Schemas outlive the code that was written against them
Applications are replaced every few years. The data survives every replacement, carrying whatever decisions were made when nobody was paying much attention.
There is a reliable pattern in long-lived systems. The application gets rewritten: a new framework, a new language, a new team, a new front end. This happens perhaps every five to eight years, and each time it is treated as a substantial undertaking. The database is migrated across, largely unchanged, because changing it is harder than changing the code and because everything else depends on it. After two rewrites the schema is the oldest surviving artefact in the system, and it is carrying decisions made by somebody who left a decade ago.
This asymmetry should change how much care goes into each. A poor choice in application code is annoying and can be fixed by somebody willing to do the work, because the code has no state. A poor choice in a schema propagates: every application written against it inherits it, every report depends on it, every integration encodes it, and by the time somebody wants to change it there are eleven consumers nobody has a complete list of.
Continue reading