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

From: David Cressey <>
Date: Sun, 16 Dec 2007 12:24:19 GMT
Message-ID: <TN89j.705$7I.145_at_trndny09>

"raylopez99" <> wrote in message
> On Dec 15, 2:30 pm, Hugo Kornelis
> <> wrote:
> > If this is the book I think it is (Pro SQL Server 2005 yadda yadda),
> > then please do me -or rather yourself- a favor and stop trying to learn
> > database theory from it. There are a lot of things that Louis and I
> > agree on, but database theory is definitely not among them. Parts of his
> > book are useful, the art is figuring out which parts.
> >
> > Best, Hugo
> Hugo are you famous? "Louis and I"? I should start hanging out here
> more often!
> In defense of Louis Davidson, his book is OK for beginners IMO (from
> what I've seen on the net) in that he uses similar examples to what
> I've seen elsewhere. If anything, the book is too plodding for me.
> Specifically on artificial keys, on p. 151 Davidson says (ironically
> or perhaps intentionally when discussing Boyce-Codd Normal Forms,
> where all attributes are fully dependent on a key):

you may well be right. But there's a problem with having beginners evaluate whether a book is OK for beginners. You don't necessarily know when the book's choice of terms or phrasing or bias is leading you down the wrong trail.

Mark Twain is quoted as saying, "it isn't what we don't know that gives us trouble; it's what we know that ain't so".

The problem with artificial keys is that they don't necessarily say anything about the real world that the data is supposed to describe. In particular, it's possible with artificial keys to make a database that is perfectly internally consistent, but unfortunately contains a whole lot of facts that ain't so. And I'm not just talking about wrong data, which can happen in any database. I'm talking about a wrong model.

Having said that, I use artificial keys freely. But I try to remember that they are artificial. They are also not "logical pointers", although I would freely call them "data links".

> "Depending on the choice of primary key this [this choice, of using a
> key for BCNF] can be a great distinction. There's a massive movement
> [note!-RL] towards using meaningless surrogate keys (of which I'm a
> big fan). [that's the author talking--RL] If you don't deal with the
> case of more than one key, it's easy to forget that the important keys
> are the natural keys of the entity, and normalization should take them
> into consideration. Too often when answering newsgroup posts [this
> means us; in other parts of the book Louis says he sometimes posts in
> Usenet groups, perhaps or in particular even this one--RL], the
> problem of poor key choices for a table has to be solved before
> solving the problem at hand".
> So, from this passage, I think the author does a good job disclaiming
> the slavish use of GUIDs without understanding their drawbacks, even
> after the author said he's a "big fan" of such GUIDs.
> RL
Received on Sun Dec 16 2007 - 13:24:19 CET

Original text of this message