Re: The problem with denormalization.

Laconic2 wrote:
> I recently ran into a place called the "Database design Blog". In
the first
> article I scanned, I read the following:
>
> "Normalize until it hurts, denormalize until it works."
<SNIP>
> Before I learned star schema, many of my denormalized databases were
> somewhat undisciplined. Using star schema allowed me to follow an
organized
> system for design, instead of merely not following the trail of
> normalization.

I don't know what star schema is, really. Well, I suppose it's like a "fact" table in the middle, and lots of "dimension" tables round the outside; but I have no idea why/where denormalisation is involved in that. My world is generally OLTP not OLAP, and I realise different considerations apply.

In my OLTP experience (with some reasonably big, but not terabyte, databases), I have never encountered a situation where I would choose to denormalise. Generally, where it has been done, it was a grope in the dark by a database designer who failed to see and fix the real issues. They often didn't even bother to quantify whether it actually improved performance, they just assumed it would. It grieves me that the requirement to denormalise is taken as given by so many designers: "this is going to be a big, multi-user system that needs to perform, so which tables shall we denormalise first?" The idea of a database with NO denormalisation would strike them as just plain wrong. That's sad.

Even in OLAP, I would want to ensure other options were considered first: for example, the use of Materialized Views to get the benefits of denormalisation (stored summaries, pre-joined tables) without the dangers (corrupt data). Received on Mon Sep 27 2004 - 15:29:33 CEST