Re: WHAT vs HOW vs WHERE

"Laconic2" <laconic2_at_comcast.net> wrote in message news:4ZydnbnwtcNGGSXdRVn_iw_at_comcast.com...
> In the ongoing discussion here about alternatives to the RM, the subject
of
> pointers keeps coming up.
>
> AFAIK, one of the features of the RM is that the interconnectedness of
data
> is established by common data values, instead of pointers.

I probably use an unacceptable def of "pointer" since I used it for any value that is in the domain of a function -- it points to something in the range of the function. In Java they use the term "reference" because they think "pointer" has a connotation of a variable that can be modified. So, a couple of questions --

1. Is a "pointer" a value, variable, other?
2. Is a Java reference a type of pointer?
3. Is the name of a relation plue the name of an attribute a pointer to the values of such? That has two parts -- Can a pointer be a literal string? and Can a pointer point to a set?

If you have a definition, even just from your head, of what you mean by "pointer" that would help.

> In my view, pointers are "good things" not "bad things". But there are
> plenty of "good things" that will harm you if you don't use them right.
One
> of the ways a network or graph data base achieves performance is by the
> efficient use of pointers, and the strategic preplacement of pointers
where
> they will be needed for navigation.

They serve as an alternative for constraints in some cases. For example, "a foreign key pointer" is not a relational theory concept where a foreign key constraint is. The idea of the pointer is that "you may navigate here" so they don't need to be as dogmatic as a "you must keep these in synch" constraint (and people who prefer one over the other might have similar traits).

> In the RDBMS implementations that used tables and indexes to represent
> relations and navigational aids, there are plenty of pointers. Indexes
> are full of pointers. And there are various kinds of pointers, behind
the
> scenes, that allow a table scan to be quicker that an entire database
scan.
> (of course, no one would ever build a product that relied on a database
scan
> for scanning a table, I hope).
>
> But tables don't have pointers in their column contents. (Except where
the
> RDBMS has a primitive datatype like DBKEY).

But the data value points to some aspect of reality, right? ;-)

> And that allows certain predictions that the RM makes to be made with fair
> certainty. That's one of the "good things" about the RM.
>
> On the subject of WHAT vs HOW, I don't even place pointers on that
> spectrum. Pointers are about WHERE, not about WHAT or HOW.

Pointers are just as much about "what" as types are. Suggesting they are about how is like saying that all of the data on a map is about how. It is about what -- if you choose to drive from one point to another, then you can use this "what" information to make decisions about how.

> Indexes
> juxtapose WHAT (the index key) with WHERE (the pointer to the row).
>
> Or am I wrong in this?

Indexes are very much about how, not what. They would be unnecessary in any system where there were no (none, nadda) performance requirements.

--dawn Received on Sat May 29 2004 - 20:59:55 CEST