Re: WHAT vs HOW vs WHERE
Date: Sat, 29 May 2004 22:40:32 +0200
Message-ID: <40b8f53c$0$48959$e4fe514c_at_news.xs4all.nl>
Dawn M. Wolthuis wrote:
> Laconic2 wrote:
>
>>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.
I know it's not me you are asking. I hope you don't mind I am still going to try (just from my head) anyway.
A pointer points to a location (where).
What your program will find there is up to the rest of the system.
A reference references something (what).
A program can get the current value
of that something by dereferencing, even if that something has been
relocated between the time of first reference and the dereferencing.
References may be implemented (how) as pointers (and a lot of
fragile computation).
The programmer prefers not to know (if he prefers to
know he should have used pointers).
What is plue? (google didn't help - plus - typo? - really I am not nitpicking, life is sometimes hard on non-native English speakers - I had to search for Student's GPA for example - I'll go for 'plus')
No. A tuple holds values conforming to the attributes of the relation. The program gets (just like in the dereferencing case) the value without ever knowing where the value resides.
Can a pointer be a literal string? It can be seen as one. Can a pointer point to a set? Not in my view - but if what is found at the location where the pointer points satisfies your idea of what a set is - sure.
>>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
There is no (visible) 'where', so indeed - it has no place in relational theory. Now if you had said reference ... ok ... stretching the meaning of the word pointer to mean reference, I assume - but to me it sounds needlessly confusing - even if you *did* warn.
> 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).
Ah... Maybe now I begin to see where you are getting at: The whole mesh of tuples can be seen as a navigatable word, re-enter the 'pointer' concept again, metaphoric 'where's. Yes, I think that would be very useful.
(If this is what you mean) it might be easier to grasp if you use less problematic words. Many people have spent some time 'unlearning' navigational thinking to (make people) understand RM.
Earlier I wrote:
[Innovation]
>> Roman numerals: i, v, x etc... >> >> i, ii, iii, iv, v, vi, vii, viii, ix, x. >> >> Arabic: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. >> >> Try one: >> 1, 11, 111, 15, 5, 51, 511, 5111, grrmpf_at_#!: 110?
> But the data value points to some aspect of reality, right? ;-)
If the datacapture is done carefully, the data reveals some aspect of reality. It does not point.
>>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.
Does, in your vocabulary, the square circle on the world map with the name 'New York' next to it 'point' to the real city? If I click on it I get data about New York. Presto! Pointing in a metaphorical sense. Point and click. Nice! But it is a different 'pointing'. I pointed at a screen/map coordinate, corresponding with a reference to the data. A lot of 'how' brought me the data. I don't think this has anything to do with what type (if any) of database was used behind this everyday scene.
>
>>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.
Yes it's about how. Putting information on where to find the rest of what we already know a part of.
BTW I agree that pointers are a "good thing" (TM). Use them wisely or corrupt your system.
:-) Received on Sat May 29 2004 - 22:40:32 CEST