Re: Newbie question about db normalization theory: redundant keys OK?

From: Knowledgy <>
Date: Fri, 14 Dec 2007 12:10:48 -0500
Message-ID: <>

A lot of it comes down to performance. For example, in a data warehouse design many times you'll see denormalized tables containing repeating groups. This is done to improve read performance, since usually data warehouse tables have a huge number of rows.

I would suggest to always create normalized data models, then build the database, test and denormalize where performance is an issue

John K
Knowledgy Consulting, LLC
Atlanta's Business Intelligence and Knowledge Management Experts

"raylopez99" <> wrote in message

> With a few hours of theory under my belt, I'd like to ask if there's
> ever a time that you don't want a completely normalized dB, that is, a
> normalized database being a dB that has no redundant information (my
> understanding of what a normalized database is).
> Or, is there ever a time that you want redundant keys (that is, the
> same keys in many different tables, that obviously are not linked (in
> a relationship) between two tables?). Having redundant attributes and/
> or keys seems to me a very lazy way of designing a database that
> doesn't require lots of initial thought, but of course you have to pay
> for it by meticulously "synching" all redundant keys to one another
> everytime there is a change in one of the redundant keys, so the keys
> don't drift and have different values.
> But is there ever a time you want to do this?
> THanks in advance
> RL
Received on Fri Dec 14 2007 - 18:10:48 CET

Original text of this message