On Sun, 16 Dec 2007 03:13:12 -0800 (PST), raylopez99 wrote:

Hi Ray,

Heh! No, I hope not. But neither do I consider Louis to be famous.

I have met Louis a couple of times, we sometimes exchange mails, and we
read (and sometimes comment on) each other's blogs. That why I know what
subjects we do and don't agree on.

(snip)
Not this one. Louis hangs around in groups specific to SQL Server. And I
believe that he nowadays spends more times in web Forums and less on
Usenet, but I'm not entirely sure.

True. But in the rest of his book, he adds a surrogate key (either GUID
or IDENTITY) to every entity before and without considering whether one
is needed. I believe that logical design should be done completely
without surrogate keys. They MIGHT be introduced during physical design,
but not before.

Best, Hugo

On Dec 16, 3:00 pm, Hugo Kornelis
<h... (AT) perFact (DOT) REMOVETHIS.info.INVALID> wrote

OK I'll keep this in mind when trying to architect a database system--
use natural keys. Which is easier said than done: how unique is
anybody nowadays ('hair color, height, weight, name, shoe size') with
300M Americans and 9B people on the planet? I'm not sure even a GUID
is 100% safe with those big numbers?! Maybe we need biometrics. But
I guess most databases are not designed to be so scalable anyway, so
perhaps natural keys are indeed the best bet.

RL

"raylopez99" <raylopez99 (AT) yahoo (DOT) com> wrote

In another topic, the distinction between "natural", "artificial", and
"surrogate" keys is being discussed. See that discussion for details. For
your purposes, you can take a key as one of the "givens", even if it's
really artificial.

(If you were to take the Latin word "data" and translate it anew into
modern English, the word "givens" might come close.)



The problem with using keys that somebody else gives you is that it isn't
under your control.
If somebody uses the same key twice, or a user enters the wrong value for a
key at initial insert time, you can be hurt by that in ways that a GUID
make it easy to recover from.

But, overall, I'm going to side with the folks who say that GUIDs add
completxity without adding power. There are exceptional situations, but if
you're looking for the general pattern, this is it.

raylopez99 wrote:

Hugo, keys are logical constructs. I fail to see their relevance to
physical design.


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.

Sometimes it is possible to invent something that has all of the above
properties. For example, when an employer assigns a number to every
employee, prints it on a card and tells each employee to include their
number on all correspondence, the employer is inventing exactly such a
key. Employers were doing that long before computers arrived.

I am not exactly sure what you mean when you say "GUID". If you mean a
128 bit number encoded in hexadecimal and broken into fields, such a
thing is neither simple nor familiar to anyone.

On Dec 17, 8:02 am, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

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

raylopez99 wrote:

There is no movement here. I am not a native english speaker,
but 'migrate' really sets you on the wrong foot.
Try to describe it in a different way.

--
What you see depends on where you stand.

On Dec 17, 12:09 pm, mAsterdam <mAster... (AT) vrijdag (DOT) org> wrote:
Louis Davidson's textbook uses the term "migrate" when a PK -->FK (PK
becomes a FK in another dB). He makes it sound like it's standard
usuage; I guess it's not-- but I like the sound of it because in those
"relationship" diagrams the keys are shown with a solid or dashed line
going to another table.

RL

raylopez99 wrote:

It is fairly common for something like an order line item to have a
compound key.

raylopez99 wrote:
I am in unfamiliar territory here, but 'becomes' still
doesn't sound right. I would use a sentence with 'references'
here, and so - I guess - would most.

--
What you see depends on where you stand.

raylopez99 wrote:
maybe we don't. Biometrics is a measurement, not a key.



rpl

stop fucking trolling.