Re: WHAT vs HOW vs WHERE

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c9ban6$k9s$1_at_news.netins.net...

> Since I was working logically (I realize that is a matter of opinion ;-),
I
> wasn't thinking about "physical" address pointers within the computer. I
> was thinking logical pointers as in navigational information from a
foreign
> key in one relation to a primary key in another (effectively a mapping).
> Also, I have worked at the higher levels in the architecture (user
interface
> and such) as well as more in systems analysis and design (and I guess I
> could admit to being a manager for well over a decade) and my formal
> education is not in computing, so I'm still learnin'.

I'm still learning, too. The only people who are not are those who think they already know it all.

There are physical addresses and there are logical addresses. Indeed, what is seen as a "logical address" at one level of abstraction is often viewed as a "physical address" at the next level of abstraction.

In the context of databases, I think an "address" is what I know as a "DBKEY". This is implementation specific. The only implementation I remember off the top of my head is DEC Rdb (Oracle Rdb). In that implementation,
a DBKEY is AREA:PAGE:LINE where AREA is an area number, PAGE is a page number within the area, and LINE is a line number within the page.

There are at least two layers of mapping that would have to be done before getting down to the "real" physical address, which mighyt be DRIVE:SURFACE:TRACK:SECTOR.

>
> I figured that address was a physical term and pointer a logical one and
> maybe that is still true?

No. A pointer, like an address, "pins" the object referenced. You can't move it without updating the pointer.

A foreign key, you will note, does NOT pin the row thus referenced. This is very important in terms of understanding the rest of the RDM. Unless you realize that data referenced by a foreign key is not pinned by that reference, the whole power of the RDM will remain largely hidden to you.

This is not just a matter of terminology.

By the way, this, to me, is one of the clues to discriminating between two groups of applications: ones that benefitted from the choice of an RDBMS (A SQL database to those of you who use that terminology), and ones that would have been better off to use CODASYL, or FOCUS, or PICK or whatever. That discrimination might be useful in your investigation of why RDBMS didn't give more bang for the buck. Received on Sun May 30 2004 - 15:12:22 CEST