[Update: I removed the reference to COBOL. It was taken the wrong way and did not add anything to the conversation. Sorry if I've hurt anyone. ]
This sin is probably one of the most prevalent of the sins I've listed thus far. I've seen it in a lot of places but it takes its worst form when there are no relations at all in the database. I'm not talking about a 4 table DB here, I'm talking a full blown tens and hundreds of tables, almost all of them without a relation to save their life.
This is a maintenance nightmare. The main reasons for this happening are usually:
Lack of knowledge\experience building and designing relational databases
Getting the wrong hands to do the DB(People with no experience\knowldge in DB design)
Not refactoring the DB when its time to. For example, you get new requirements and one of them turns a 1 to 1 relationship into a 1 to many relationship, but no one bothers to change the DB to accommodate. It's “too much work“. So they just pile up more rows or whatever else structures into the existing table instead.
After enough time has passed, you can't even refactor the DB anymore. Theres too much junk on it and anything you do breaks something terribly big.
the main downsides:
You don't let the database provide an extra layer of confidence, especially data integrity rules, in which relational databases excel and make life very easy.
No one will be able to understand what the hell goes on in your DB without the dedicated help of the person who built it. That's trouble waiting to happen.
You won't be able to create pretty diagrams of the database with logical connections in them, although mentally these relations are there. They are just transparent and as weak as the code you wrote to protect them. You also won't be able to use automated code generators, object model generators and the like. Your DB is not speaking the universal language of DB description. It's all in your head.
Everyone will laugh at you in the newsgroups. (I bet that's the most potent argument yet!). Then again, if you create such a database, you probably don't read any newsgroups relating to these issues, do you?
Solution: Get a good DBA already! Or, train someone in the fine art of relational databases. It's not that hard and it will save you huge amounts of money in the long run.
Previous Topic
