Databases rot over time

Your original database design was great and the system has been running fine for a couple of years. The original developers had all done their jobs well, received their bonuses and moved on to new projects or new jobs. So why is everything starting to fall apart now?

Squeezing round pegs into square holes

The current developers who inherited the system are faced with a simple choice every time they need to add new functionality:

• Alter a complex design and rewrite all interdependent code (feeds, screens, searching, integrity checks)
  
• Just squeeze the additional functionality into the existing database structures that weren't designed for that purpose.

The first option may be technically correct but costs the most and carries the most risk if it all goes wrong. The second option is cheap to implement and can always be rolled back out if things go wrong.

The problem with this second option is it leads to a slow rotting of the database design (assuming it was any good in the first place). New code needs to be added to deal with each of these new exceptions.

Pretty much the same thing happens when scope creep raises its ugly head in the later stages of development.

So what happens?

Functionality decreases, bugs appear, performance starts to decrease, maintenance costs start to increase.

Those generic stored procedures that worked with any item stored in the table now don't work for the new items that are now being stored there. This leads to extra code being written to cope with the exceptions. The exceptions mount up until your system becomes the maintenance nightmare we all dread.

Performance starts to appear random depending on which set of exceptions are needing to be called.

Functionality also starts to appear random as the exception code deviates more from the original logic.

Poor integrity checks
Saving time by not implementing integrity checks on your data means that bad data will creep into your database. When errors appear in your code that leads to a Allowing bad data into your database means doesn't save time. It just means that all the rest of the code in the database now needs to protect itself against this bad data.