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

From: raylopez99 <raylopez99_at_yahoo.com>
Date: Sat, 15 Dec 2007 08:37:16 -0800 (PST)
Message-ID: <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.

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 Received on Sat Dec 15 2007 - 17:37:16 CET

Original text of this message