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

"raylopez99" <raylopez99_at_yahoo.com> wrote in message news:2a3ccdf5-5341-4494-8dce-070f9b34cf6d_at_e4g2000hsg.googlegroups.com...
> 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.
>

I would have to look at the comment in context to fully evaluate it. On the surface, it looks like fluff. Codd's idea of using the relational data model as a basis was NEVER based on extreme economizing of computer power. If you go back to the origins of the RDBMS products in the 1970s, you will find that, in almost every case, relational systems used more computer power than database systems based on pointers, like for example IMS.

Indeed, it was the growth of computing power during the 1980s that facilitated the growth of relational databases, and the relative stagnation of databases based on what the mathematicians call "graphs". I say "facilitated" but that wasn't the prime driver.

> 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".
>

Avoiding pointers has little to do with saving memory. It has a lot to do with avoiding the pitfalls inherent in permitting the data structure to carry information that is better carried by the data itself.

> 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).
>

It depends on what you mean by "a lot of work". The people who promote alternatives to the relational model consistently overstate the amount of work it takes to set up a good schema of relational tables ("relvars" if you like). And they consistently understate the amount of fleixibility that such a schema has in the face of unforeseen query requirments.

In any event, as you learn Microsoft Access, you are much better off to learn some good relational modeling techniques, than to plan on building artificial intelligence into your applications.

> RL
Received on Sun Dec 16 2007 - 12:05:52 CET