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

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

-- 
Sincerely,
John K
Knowledgy Consulting, LLC
www.knowledgy.org
Atlanta's Business Intelligence and Knowledge Management Experts


"raylopez99" <raylopez99_at_yahoo.com> wrote in message 
news:15b312ea-1f66-4f22-abbb-63581e0eca73_at_x69g2000hsx.googlegroups.com...


> 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