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

raylopez99 wrote:

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

raylopez99 wrote:

With all due respect, from your description of what Davidson writes, he
sounds like an idiot. Just more evidence that our industry regresses.


The RM (relational model) has nothing to do with physical pointers or
memory. The whole point of the RM is to divorce logical considerations
from physical considerations so that one can specify what one wants
separately from how one expects the dbms to deliver it.

Indexing, clustering, and physical pointer chains happen at the physical
level independent of the logical design. This is extremely important
because it allows one to change the performance characteristics of the
database without breaking every application ever written to use the
data. Think about it.

[snip]

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

There have in the past been trends towards suspecting neighbours of being
witches; colleagues of being communists; thinking that rocks as pets is
funny; a new ice age is imminent; shoulder-pads and big hair make women
attractive, and...well the list goes on. Trends don't mean a thing. A
trend is just a mild form of mass hysteria.

It does not. It is only familiar, so you have stopped thinking about
whether it makes sense or not.

Precisely. And it is a non-trivial point. I can't quantify the cost of the
alternative, but it is huge.

Good luck with that! :-)

Sure, and there is no problem with doing that under the covers; it would be
ideal if we could do that. But everything pointing to everything would be
intractible unless we have a simple, regular, well-behaved way to express
our search requirements. The relational model provides that without
excluding any implementation.

Roy

On Sat, 15 Dec 2007 08:37:16 -0800 (PST), raylopez99 wrote:

Hi Ray,

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

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

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.


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.


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.

On Dec 15, 2:30 pm, Hugo Kornelis
<h... (AT) perFact (DOT) REMOVETHIS.info.INVALID> wrote:

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

"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

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

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

"David Cressey" <cressey73 (AT) verizon (DOT) net> wrote


A very excellent saying to be sure, but I think it is actually attributed to
Charles Browne, writing under the pseudonym Artemus Ward.

Roy

"Roy Hann" <specially (AT) processed (DOT) almost.meat> wrote

I've seen it attributed to Mark Twain. But then again, that could just be
one of those things I know that ain't so.