Re: Navigation question
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 23 Feb 2007 16:24:49 GMT
Message-ID: <lzEDh.294$PV3.4920_at_ursa-nb00s0.nbnet.nb.ca>
>>On Feb 22, 6:34 pm, mAsterdam <mAster..._at_vrijdag.org> wrote:
>>
>>>dawn wrote:
>>>
>>>>mAsterdam wrote:
>>>>
>>>>>dawn wrote:
>>>>>
>>>>>>In another thread "navigation" is again mentioned as undesirable.
>>>
>>>[snip]
>>>
>>>
>>>>>Nothing good, nothing bad here, just: navigation is something that
>>>>>does not exist within the RM.
>>>
>>>>Right.
>>>
>>>[snip]
>>>
>>>
>>>>>'From a fk in a child to a parent tuple'
>>>>>is at best metaphor (and btw. borrows hierarchical terms).
>>>
>>>>Do these terms properly communicate so that you know what I mean,
>>>
>>>No.
>>
>>Let's say you are looking at a report, on paper, showing a set of
>>attribute names and values for a Person with personId="77777"
>>fmName="Danni Lynn" mother="11111". You put your finger on Danni
>>Lynn's mother value. Then you realize that on that same piece of
>>paper there are more values from the Person relation listed, including
>>one with personId="11111" and fmName="Anna Nicole".
>>
>>So, you move your finger from "11111" as a value of the mother
>>attribute to the "11111" that is a value of the personId attribute for
>>another Person. This was physical navigation. You moved your finger
>>on the paper.
>>
>>However, there is logical navigation that corresponds to this, where
>>there was no need to move your finger as there is an algorithm that
>>"goes from" the mother of one person to the personId of another. This
>>algorithm is one example of going "From a fk in a child to a parent
>>tuple"
>>
>>Now encode some bytes on a disk drive, for example, so that the
>>logical interpretation of them is similar to what is on our paper
>>(although the physical representation might be very different). The
>>physical representation might even span disk drives. It has an
>>algorithm that could be quite different from a corresponding logical
>>(application coded) navigation. The application level, logical level,
>>navigation would be at a higher level of abstraction than any physical
>>navigation.
>>
>>
>>>>or is there some better way to say this?
>>>
>>>AFAIK not yet. Please stay focused and don't state your questions
>>>as loaded as this.
>>
>>The question is whether the logical navigation described above has
>>something inherently "bad" about it so that we must always avoid
>>coding such navigation into our applications (combination of metadata
>>and code, for example).
>>
>>Granted there are pros and cons to our choices of algorithms, so that
>>there might be a reason to use set-based logic to retrieve Danni
>>Lynn's mother in some situation, but is there a reason that navigating
>>(logically) is necessarily a poor choice?
>>
>>[I cannot resist mentioning that for a possibleFather attribute, it
>>might be helpful to use a multivalued attribute, but that is another
>>story entirely,]
>>
>>
>>>>>You want to discuss navigation? Ok. The RM will not proliferate
>>>>>vocabulary. Furthermore, the first thing people will associate
>>>>>it with is the physical level hidden by the DBMS. You have clearly
>>>>>stated that that is not what you want to talk about.
>>>
>>>>Correct.
>>>
>>>>>Let's go navigating the database - not at the physical level, but
>>>>>somewhere else; 'Navigating foreign keys', example:
>>>
>>>[snip example - people who want to read it should navigate up the nntp
>>>tree]
>>>
>>>
>>>>Yes. My understanding from responses to date is that thie type of
>>>>navigation is not considered bad and not considered logical
>>>>navigation, but more of a user interface conceptual navigation. Each
>>>>user event permits us to start anew so that the code does not navigate
>>>>the database, only the user does. So, while the physical is at a
>>>>lower level than I want to discuss navigation, user-event driven
>>>>"navigation" of a database is at a higher level.
>>>
>>>The physical stuff is lower, so this must be higher, right?
>>>Well, I do not think so. Earlier, maybe, part of it.
>>>
>>>(For the RM-only zealots out there I am thinking of the
>>>place in time in the whole of the construction/growth of
>>>databases, not just the moment from which all is clear and downhill
>>>sliding after - after the specs have been signed, sealed and
>>>delivered. Yes, this is database theory. RM-only zealots are stupid,
>>>not just ignorant: "Men are born ignorant, not stupid. They are made
>>>stupid by education." -- Bertrand Russell
>>>)
>>
>>While I understand Russell's point, I'm missing yours, but I guess the
>>parenthetical comment was not intended for me, eh?
>>
>>
>>>As soon as someone tells me something is 'higher level'
>>>I think: on which stairway?
>>>
>>>Higher level - than what? why is it higher? How do you measure that?
>>
>>Add 8 "User Layer" to the OSI layers. My questions are regarding
>>layer 7, where "logical navigation" of a database might take place.
>>Does that work for you? --dawn
Date: Fri, 23 Feb 2007 16:24:49 GMT
Message-ID: <lzEDh.294$PV3.4920_at_ursa-nb00s0.nbnet.nb.ca>
Walt wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message > news:1172196356.504564.212670_at_v33g2000cwv.googlegroups.com... >
>>On Feb 22, 6:34 pm, mAsterdam <mAster..._at_vrijdag.org> wrote:
>>
>>>dawn wrote:
>>>
>>>>mAsterdam wrote:
>>>>
>>>>>dawn wrote:
>>>>>
>>>>>>In another thread "navigation" is again mentioned as undesirable.
>>>
>>>[snip]
>>>
>>>
>>>>>Nothing good, nothing bad here, just: navigation is something that
>>>>>does not exist within the RM.
>>>
>>>>Right.
>>>
>>>[snip]
>>>
>>>
>>>>>'From a fk in a child to a parent tuple'
>>>>>is at best metaphor (and btw. borrows hierarchical terms).
>>>
>>>>Do these terms properly communicate so that you know what I mean,
>>>
>>>No.
>>
>>Let's say you are looking at a report, on paper, showing a set of
>>attribute names and values for a Person with personId="77777"
>>fmName="Danni Lynn" mother="11111". You put your finger on Danni
>>Lynn's mother value. Then you realize that on that same piece of
>>paper there are more values from the Person relation listed, including
>>one with personId="11111" and fmName="Anna Nicole".
>>
>>So, you move your finger from "11111" as a value of the mother
>>attribute to the "11111" that is a value of the personId attribute for
>>another Person. This was physical navigation. You moved your finger
>>on the paper.
>>
>>However, there is logical navigation that corresponds to this, where
>>there was no need to move your finger as there is an algorithm that
>>"goes from" the mother of one person to the personId of another. This
>>algorithm is one example of going "From a fk in a child to a parent
>>tuple"
>>
>>Now encode some bytes on a disk drive, for example, so that the
>>logical interpretation of them is similar to what is on our paper
>>(although the physical representation might be very different). The
>>physical representation might even span disk drives. It has an
>>algorithm that could be quite different from a corresponding logical
>>(application coded) navigation. The application level, logical level,
>>navigation would be at a higher level of abstraction than any physical
>>navigation.
>>
>>
>>>>or is there some better way to say this?
>>>
>>>AFAIK not yet. Please stay focused and don't state your questions
>>>as loaded as this.
>>
>>The question is whether the logical navigation described above has
>>something inherently "bad" about it so that we must always avoid
>>coding such navigation into our applications (combination of metadata
>>and code, for example).
>>
>>Granted there are pros and cons to our choices of algorithms, so that
>>there might be a reason to use set-based logic to retrieve Danni
>>Lynn's mother in some situation, but is there a reason that navigating
>>(logically) is necessarily a poor choice?
>>
>>[I cannot resist mentioning that for a possibleFather attribute, it
>>might be helpful to use a multivalued attribute, but that is another
>>story entirely,]
>>
>>
>>>>>You want to discuss navigation? Ok. The RM will not proliferate
>>>>>vocabulary. Furthermore, the first thing people will associate
>>>>>it with is the physical level hidden by the DBMS. You have clearly
>>>>>stated that that is not what you want to talk about.
>>>
>>>>Correct.
>>>
>>>>>Let's go navigating the database - not at the physical level, but
>>>>>somewhere else; 'Navigating foreign keys', example:
>>>
>>>[snip example - people who want to read it should navigate up the nntp
>>>tree]
>>>
>>>
>>>>Yes. My understanding from responses to date is that thie type of
>>>>navigation is not considered bad and not considered logical
>>>>navigation, but more of a user interface conceptual navigation. Each
>>>>user event permits us to start anew so that the code does not navigate
>>>>the database, only the user does. So, while the physical is at a
>>>>lower level than I want to discuss navigation, user-event driven
>>>>"navigation" of a database is at a higher level.
>>>
>>>The physical stuff is lower, so this must be higher, right?
>>>Well, I do not think so. Earlier, maybe, part of it.
>>>
>>>(For the RM-only zealots out there I am thinking of the
>>>place in time in the whole of the construction/growth of
>>>databases, not just the moment from which all is clear and downhill
>>>sliding after - after the specs have been signed, sealed and
>>>delivered. Yes, this is database theory. RM-only zealots are stupid,
>>>not just ignorant: "Men are born ignorant, not stupid. They are made
>>>stupid by education." -- Bertrand Russell
>>>)
>>
>>While I understand Russell's point, I'm missing yours, but I guess the
>>parenthetical comment was not intended for me, eh?
>>
>>
>>>As soon as someone tells me something is 'higher level'
>>>I think: on which stairway?
>>>
>>>Higher level - than what? why is it higher? How do you measure that?
>>
>>Add 8 "User Layer" to the OSI layers. My questions are regarding
>>layer 7, where "logical navigation" of a database might take place.
>>Does that work for you? --dawn
> > what do you mean by "OSI layers?" Are you talking about layers of > protocols? If so, it seems to me that application to > database theory is limited to the areas where data is exchanged in some sort > of formal protocol. That sounds to me like the interface between the client > (application software) and the server (DBMS software). If that layer uses > SQL to express queries and updates, and some sort of data representation to > pass result tables, then I would suggest that those who have said that > "navigation is impossible at this layer" are correct. > > Whether applications should or should not navigate within their own data > space is really not a question for database theory, is it?
I refer you to Date's _Principle of Incoherence_. Please stop feeding the troll. Received on Fri Feb 23 2007 - 17:24:49 CET