Mortal sin: A non-relational relational database.

[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.
Published Thursday, February 19, 2004 3:55 PM by RoyOsherove
Filed under:

Comments

Thursday, February 19, 2004 2:26 AM by TrackBack

# My Worst Database Experience Ever

My Worst Database Experience Ever
Thursday, February 19, 2004 9:01 AM by vinnie tripodi

# re: Mortal sin: A non-relational relational database.

Why does everyone beat on us old Cobol guys? What does Cobol have to do with designing a relational database?
Thursday, February 19, 2004 9:32 AM by Anonymous

# re: Mortal sin: A non-relational relational database.

You can't export or imort databases easily with dts, when relations are defiened in the database. This gave me one hell of a bad time! The Database is the wrong place for documentation.
Thursday, February 19, 2004 9:34 AM by Scott Galloway

# re: Mortal sin: A non-relational relational database.

Yeah, a bit mean on the COBOL guys...also worth remembering that they're probably all loaded after the whole Y2K debacle - never hurts to have rich friends! Anyway, my next biggest DB issue (after yours which is THE biggy) is incorrect / poor use of indexes...grr...it doesn't matter how smart your query is or how good your relations are, if your indexes are crap / non-existent, the performance will suck!
Thursday, February 19, 2004 9:34 AM by t

# re: Mortal sin: A non-relational relational database.

reasons to have DB without relations :
1 . if you have a replications of youre DB sometimes you need to have DB without relations .
2. it works faster without relations
Thursday, February 19, 2004 9:40 AM by Yura2000

# re: Mortal sin: A non-relational relational database.

Hi Roy,
Ocasionally I am using not normalized DataBases .
And such cases are exactly when you have super cumbersome logic and huge amout of records.
From the second side you requested aftest perforamnce for reports, ubpdates etc. and hundreds hits in minute for your web application.
And more, I spoke about DB thet was normalized in the early life's stages.
Thursday, February 19, 2004 9:42 AM by Yura2000

# re: Mortal sin: A non-relational relational database.

//After code review :-))
Hi Roy,
Ocasionally I am using not normalized DataBases .
And such cases are exactly when you have super cumbersome logic and huge amout of records.
From the second side you requested for fastest perforamnce for reports, updates etc. and hundreds hits in minute for your web application.
And more, I spoke about DB that was normalized in the early life's stages.
Thursday, February 19, 2004 11:10 AM by Roy Osherove

# re: Mortal sin: A non-relational relational database.

Of course sometimes you HAVE to remove relations. I'm not talking about the exceptions to the rule here. I'm talking about people not implementing the rule when the can and SHOULD implement it.
Thursday, February 19, 2004 12:11 PM by Rich

# re: Mortal sin: A non-relational relational database.

This is a little confusing. If the database has a single table and the table has a single column, then it has a relation. It sounds like you are really talking about relational integrity, i.e., the relationships between relations (tables).
Friday, February 20, 2004 5:14 AM by Michael Dorfman

# re: Mortal sin: A non-relational relational database.

Roy *is* speaking about relational integrity, and a database without it isn't really a relational database. In order for a "single column table" to be a table (in a relational sense) the single-column has to be defined as a primary key, with a unique constraint. The fact that SQL Server allows you to do otherwise is the root of the problem. It's all too easy in SQL to create a "table" with no primary key, or omit a foreign key constraint, and before you know it you are writing funky business logic to enforce rules that should be in the database. Or, more likely, finding weird bugs because you forgot to write the funky business logic.
Friday, February 20, 2004 8:09 AM by TrackBack

# My personal DB hell