Re: Newbie question about db normalization theory: redundant keys OK?
Date: Fri, 14 Dec 2007 12:10:48 -0500
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
Knowledgy Consulting, LLC
Atlanta's Business Intelligence and Knowledge Management Experts
"raylopez99" <raylopez99_at_yahoo.com> 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
Received on Fri Dec 14 2007 - 18:10:48 CET