Re: Navigation question
Date: Fri, 23 Feb 2007 16:10:02 GMT
Message-ID: <ulEDh.4$t2.0_at_trndny05>
"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.
>> > AFAIK not yet. Please stay focused and don't state your questions
> > > or is there some better way to say this?
> >
> > 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,]
>> > stupid by education." -- Bertrand Russell
> > >> 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
> > )
>
> 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? Received on Fri Feb 23 2007 - 17:10:02 CET