Peter Harkins succinctly distills out rules of database app aging, namely that fields become optional, and relationships become many-to-many. When I read that I wanted to add,
but commenters have already extended the list.
One comment on the blog post in particular caught my eye. Jonathan Holland said,
This sounds more like database aging when your original schema was poorly planned.
I don’t know what world Jonathan is working in. In my experience, these sorts of aging effects of applications are due not to developers doing a sloppy job as they are due to the domain needs changing. Sure, sometimes, developers try to ignore inconvenient stuff like timezones, but much of the time, the application needs change. When designing the schema for version 1, it’s impossible to predict what version 3 will need. Trying to anticipate it won’t guarantee your schema won’t change, it will just mean you do a lot more work in version 1, and then version 3 turns out to be completely different than you expected, so not only does your schema stretch in difficult and unexpected ways, but half the flexibility you built in turns out to be completely unhelpful and possibly even a crushing burden.