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

raylopez99 wrote:
> My beginner's book on RDBMS theory by Louis Davidson (APress) says
> that there's a trend towards using GUIDs (artificial keys) as
> computing power increases.
>
> This makes sense, though I do appreciate the point made by a poster
> here that if you use compound keys you have "built in" protection
> against accidentally inserting the same data by mistake, rather than
> having to programmically guard against this.
>
> Just point out what the textbook says, not trying to start any flame
> wars... hahaha.
>
> Another thing: has it occurred to anybody (and sorry if this idea is
> old) that the Codd RDBMS scheme of PK/FK/Constraints is a way of
> avoiding pointers and saving memory? If you have infinite memory,
> infinite computing power, and pointers, just link everything to
> everything, and then you can ask a query like "where does the group of
> people who met last July 3, 2007 in a room ABC to listen to a
> presentor lecture on the US Constitution for a course called
> Constitutional History 101 next meet?" The program will figure it
> out, using a probability analysis, since if there were 100 people,
> including the professor, who got married and changed her name on July
> 4th, and everybody is linked to everybody else, you can see where the
> next lecture is for 99 out of 100 people, and tell them. The one
> person (the teacher) who changed their name, well there's enough
> 'redundancy' in the system (the exact opposite of the Codd model) so
> that she'll get an update for the next meeting place anyway, since
> she's no doubt linked with the other 99 people in some way or another--
> not by name, but by the fact that on July 3rd she was in a building X
> with 99 other people at the same time of day, so ergo she must be the
> teacher (by process of elimination), even if she now has a new name.
> What happens if she doesn't check her old or new email is another
> matter however, but that's not the database's problem, that's called
> "human error".
>
> Using the traditional Codd model you also can say that if every
> attribute to the entity table(s) "StudentTeacherCourse" et al. are 3NF
> and beyond complete, then you also solve this problem, but it takes a
> lot of work to construct this table(s)--isn't it better to throw
> everything in a bin, link it to everything else, and let an inference
> engine sort out the probabitlies? Methinks so, at least someday in
> the future (AI).
>
> RL
The short answer is NO!

One of the major benefits of Codd's model is the elimination of any dependencies on the physical location of data.

Pointers to physical locations are a major maintenance nightmare. When using them additions, deletions and changes can all force the reconstruction of the entire database. While this might be acceptable in your 100 person example it would prove intolerable in a large commercial database (one of the primary reasons why Codds' model was so

   widely adopted in spite of its inferior performance on the systems available 30 years ago.)

HTH
Jerry Received on Sat Dec 15 2007 - 18:14:55 CET