Newbie question about db normalization theory: redundant keys OK?
From: raylopez99 <raylopez99_at_yahoo.com>
Date: Wed, 12 Dec 2007 14:26:36 -0800 (PST)
Message-ID: <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).
Date: Wed, 12 Dec 2007 14:26:36 -0800 (PST)
Message-ID: <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 Received on Wed Dec 12 2007 - 23:26:36 CET