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

On Dec 15, 6:07 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Ray, the design criteria for keys are: familiarity, simplicity,
> stability, uniqueness and irreducibility. Sometimes the criteria
> conflict, and design involves tradeoffs.
>
> If one has a very simple predicate with a handful of attributes that are
> all foreign keys to other relations and with no references to itself,
> then familiarity, stability, uniqueness and irreducibility will trump
> simplicity.
>
> Other situations are less clear-cut.

Thanks Bob Badour, this was helpful. In my mind, it means we should look to populate the tables (entities) with keys that are orthogonal and describe the entity, the attempt to migrate (a term my book uses) one or more primary keys as foreign keys to the next entity that has to have a relationship with the first entity, and so on, using Einstein's dictim to simplify but not oversimplify, until an architecture is built that is robust enough to later take in new information without having to do a lot of triggers/updates/programming tricks to globally replace previously entered data and/or accomindate new data not foreseen. A daunting task, since you have to describe the present and forecast the future. And of course I'm not just talking about something like the Y2K two-digit date problem (though that is a specific instance of this general problem).

Me, I code for fun. Also I'm essentially recreating for my family and myself a program that Microsoft sells called "Money". It's more fun when the program is home brew, and my folks will not buy an commerical program so it's a good way for me to make sure they track their money properly (right now they're using paper and pencil, and it's incredibly inefficient).

Bye,

RL Received on Sat Dec 15 2007 - 16:41:24 CET