Re: Conceptual, Logical, and Physical views of data

From: Marshall Spight <marshall.spight_at_gmail.com>
Date: 10 Sep 2005 16:09:06 -0700
Message-ID: <1126393746.050990.311620_at_g43g2000cwa.googlegroups.com>


dawn wrote:
> > >
> > > I don't yet see how a URL is more of a pointer than a foreign key. It
> > > is an identifier. You can use it to "go to" another source of data
> > > just as you can use a foreign key to "go to" another source of data.
> > > It doesn't even point to a machine, even if it resolves to know what
> > > machine to go to. My foreign key used in a join statement knows that
> > > too.
> >
> > We already discussed this to death. :-(
>
> I know and I apologize for not yet understanding. This pointer issue
> seems one of the big motivators for relational theory, so I want to
> "get it". I understand why this was problematic when related to memory
> locations, but I don't understand the big downside of using logical
> pointers, reference values, foreign keys -- what's the difference?

Well, we should first of all be clear when we are talking about one thing being better than another vs. when we are talking about one thing being different from another. Mostly lately I've been trying to focus on the *difference* between location-based addressing and content-based addressing. I'm going to try to leave out the "which-is-better" in part because it's not really fruitful to discuss until we're clear on the differences, anyway.

As an aside, let me just relate that about 2 years ago, I had a lengthy discussion at work in which it was me vs. 2 guys with CS Ph.Ds, with them taking the position that there's no difference between a pointer and a foreign key. At the end of about a week, they were unmoved. (Normally that would give me pause, but it didn't in this case because I've read a lot more about relational theory than they had, and because, well, uh, I'm right. Even though: no graduate education <sob>.)

Anyway: it's a small and subtle difference.

The single most telling distinction between an address and a foreign key is this: in a system with foreign keys, you have to have a special operator that given an address returns its referent, and an inverse special operator that given a referent returns its address. With content-based addressing, there simply is no such operator; the comparable functionality is available already just from being able to address data via its content.

Also: the pointer is *external* to the data referred to, whereas the foreign key is integral to the data.

Have you ever programmed in C or C++? (Non-rhetorical question.) You know the * and & operators? That's them.

(In Java, the situation is obscured by the fact that both operators are made implicit; there's no syntax for them. In Java, when you mention a pointer, the only thing you could mean is its referent, so the dereference operator is automatic. Likewise, the only way to aquire a pointer in Java is via "new", so the reference operator is again built in.)

Can you find anything even vaguely similar is SQL? The closest would be something like

"select * from Customers where CustomerId = 1234"

but where is the pointer operation? It's not "where" because that can mean a zillion things; you could just as well as said "where LastModified > '1-1-2000' and CreditLimit > 1000" and *that's* not a pointer operation. And it's not the '=' operator, either.

Part II has to wait for later, because we've got a sitter and it's time to go visit friends. Hurray for sitters!

Marshall Received on Sun Sep 11 2005 - 01:09:06 CEST

Original text of this message