Re: Trend towards artificial keys (GUIDs) sez my textbook...is AI next?

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 17 Dec 2007 16:42:50 -0400
Message-ID: <4766df4a$0$5286$9a566e8b@news.aliant.net>

raylopez99 wrote:

> On Dec 17, 8:02 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
>

>>Ray, there is no simple rule. The design criteria for keys are:
>>simplicity, familiarity, stability, uniqueness, irreducibility.
>>
>>You would do yourself a favour by writing them on a post-it note right
>>about now.
>>
>>Sometimes they conflict and one has to make tradeoffs. The ideal key
>>will have all 5 of those properties. Sometimes no such ideal key exists.
>>At such times, one must understand why each of the above properties is
>>important and what problems will ensue from not having the property.

>
>
> Bob thanks for that link to the 1989 poster "Five Rules of
> Normalization" involving the Puppy Kennel. Very useful, I've gone
> over it several times (still can't figure out Rules 4 or 5 but I'll
> get it eventually).
>
> Today I learned that Access will not give you an error if you create a
> relationship (i.e. migrate a primary key to another table as a foreign
> key) between two tables where the second table has a *compound*
> primary key that includes a PRIMARY key of the first table (!). I
> didn't know that you could do that, I assumed you never could use a
> primary key as the primary key of another table, but it makes sense
> since you're not really using a primary key again, since the second
> table has a _compound_ primary key. Now something tells me that this
> compound key is probably not a good key, since it seems to violate
> 2NF, but that's another point.
>
> Learn something new everyday.
>
> RL

It is fairly common for something like an order line item to have a compound key. Received on Mon Dec 17 2007 - 14:42:50 CST