Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Navigation question

Re: Navigation question

From: Walt <wamitty_at_verizon.net>
Date: Sat, 24 Feb 2007 20:37:57 GMT
Message-ID: <Fm1Eh.9293$t2.5470@trndny05>

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1172288572.395343.29690_at_h3g2000cwc.googlegroups.com...
> On Feb 23, 7:00 pm, mAsterdam <mAster..._at_vrijdag.org> wrote:
> > dawn wrote:
> > > mAsterdam wrote:
> > >> dawn wrote:
> > >>> mAsterdam wrote:
> > >>>> dawn wrote:
> > >> [snip]
> > >>>>> Add 8 "User Layer" to the OSI layers. My questions are regarding
> > >>>>> layer 7, where "logical navigation" of a database might take
place.
> > >>>> The OSI layering hides the complexity
> > >>>> in the lower layer from the layers above it by hiding
> > >>>> the concepts in the lower layer from the one above it,
> > >>>> except for a clean request/service interface.
> > >>>> By using RM terms (what layer is that? - hm, dunno,
> > >>> It is layer 7, the application layer. The RM relates to the
interace
> > >>> between app code and the DBMS, both of which are application layer.
> > >> So 7d and 7a? Sub layers? I don't get it.
> > > 7, just 7. Do you have some other take on it?
> >
> > This was an attempt to find out what you mean.
> > I thought you introduced the OSI layers to explain
> > which navigation you want to talk about.
> > Not navigating disk space or memory space,
> > in which space is the navigation taking place
> > you /do/ want to talk about? See below.

>

> Application software (which includes DBMS and database), layer 7
>

> > >>>> but for the
> > >>>> argument it only matters that it is lower than 8 in your stack)
> > >>>> in the added layer 8 you are doing the opposite.
> > >>> Not tracking with you, the opposite of what?
> > >> The opposite of hiding the complexity in the lower layer
> > >> from the layers above it by hiding the concepts in the lower
> > >> layer from the one above it ...
> >
> > (>> ... by mixing the terms.)
> >
> >
> >
> > > I accept that whatever the user is doing need not be coupled to what
> > > the application software is doing. I was looking at different places
> > > for "navigation" and trying to figure out what, precisely, is the
> > > navigation that is frowned upon and why, precisely, is it frowned
> > > upon.
> >
> > ISTM it is highly context sensitive why something is frowned upon.
>

> Yes.
>

> > What navigation was frowned upon?
>

> That's one of my questions here.
>

> > Why was it frowned upon?
>

> That's the other.
>

> > Was that navigation itself or the inappropriate use of the term?
>

> I don't know, but wherever there are RM advocates there seem to be
> people looking down on "navigation." So, what is this bad navigation
> and why is it bad? I'm trying to zero in on this.
>

> > Who frowned?
>

> Codd, Date, JOG (the big three ;-) for starters.
>

> > Taken in isolation it doesn't mean much if anything.
> > Why should I care?
>

> That's a question for you.
>

> > Maybe you are hinting at this:
> > Using a CODASYL or hierarchical DBMS it is inevitable
> > that programmers think of navigating the network or the tree:
> > next, prior, up. The network and the tree or dag
> > are the spaces they have to navigate. When there
> > is no such space there is no need to navigate.
> > Navigating where there is no space may be frowned upon.
>

> Are you suggesting that RM folks only frown on navigating within the
> RM, rather than "within the database" when we have already agreed
> there is no such thing as navigation? So, is there and argument
> something like this: It is OK to navigate within a database as long as
> we are not using the RM, but we must use the RM, therefore we are
> opposed to database navigation. Additionally, the RM is superior
> because it does not rely on or "do" database navigation. Why does
> that make it superior? Because it is better not to navigate? What is
> it better not to navigate? Because navigation is not part of the RM.
>

RM folks assert that using the RM is superior to relying on navigation in order to juxatpose related data at retrieval time.

The downside of having to rely on navigation has been amply described in the literature. You don't need any of us to recapitulate that for you.

> I'm not finding a way out of this circle. So far I have not heard
> anything that would cause me to think that database navigation should
> be considered an anti-pattern rather than a pattern for use in
> developing application software. Have you?

>

> > Again, without context it doesn't really matter, does it?
> >
> > > At this point I am now asking more specifically about
> > > navigation in the application layer of the software. That includes
> > > all components of applications and application suites, including the
> > > database and the DBMS.
> >
> > >>> I'm agreeing with some who have
> > >>> suggested that when we are talking about the user navigating, via
the
> > >>> code (layer 8), that does not imply we are navigating in layer 7.
> > >> ... by mixing the terms.
> >
> > > Which terms am I mixing?
> >
> > Foreign keys and links, for example.
> > Documents and data - how many time have you called the web a database?
>

> None in this thread. Sometimes I'm sensitive to my audience ;-) I
> fully expect that at some point you will perceive the web as a
> database too (highly distributed as it is). I'm not thinking of it as
> "semi-structured" data, but as structured data, where "pages" are
> values in this database, just like comments are values in databases
> and URLs are key values.
>

> > >>>> earlier:
> > >>>> > 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).
> > >>>> This would be about the application layer, right?
> > >>> Yes.
> > >>>> (and still good/"bad", and still "logical navigation".)
> > >>> Yes. So, your answer is...?
> > >> Mu.
> >
> > > and I adore you too, mAsterdam, but no matter how I form this question
> > > I am either not getting straight answers or not understanding them.
> >
> > Have you considered the possibility that that might be
> > due to the question?
>

> Yes, it has occured to me that this is a question that either a) I am
> not framing well or getting across for some reason or b) some are not
> able to step outside of the RM to answer them or c) I am asking and
> others are understanding but do not wish to answer, perhaps due to
> having a "belief" they think has been proven, but where the proof
> isn't coming to them anymore than it is to me.
>

> > > I really would like to get to the point where I fully comprehend just
> > > what navigation is to be avoided and why. In particular, is either of
> > > the following an anti-pattern?
> >
> > > 1. DBMS includes metadata specifications for "links" so that it is
> > > able to "navigate" when questions are asked that require such.
> >
> > To much roman numerals.
> > Is this a correct arabic rephrase?
> >
> > 1. The catalog can be queried in order to generate
> > relevant queries on the fly.
>

> Not really. How about this -- The database can be queried, via the
> DBMS, and the combination of the query statement and the catalog
> provides the information for the DBMS to logically navigate to
> retrieve the data.
>

> > No navigation going on at the interface between
> > program and dbms, but the user may experience
> > using this feature as navigating the database.
>

> Ugh! What about my Anna Nicole example? The query asked for the
> mothersName, which is a virtual field defined (user-defined function,
> stored-procedure-ish) that includes a specification to use the
> motherId as the key to Person and then retrieve the mother's name from
> that tuple. Jump outside of the RM. Software does this. Many DBMS's
> do this. Developers do this. It works. Is it a pattern or an anti-
> pattern?
>

> > The user interface may even be designed to emphasize
> > this.
>

> Let's stick to layer 7, brother. Is there any chance that I am going
> to be able to ask this question in a way that you will be able to
> answer it in a way that I will be able to understand your answer?
> cheers! --dawn

>

Based on the recent past... not for the foreseeable future.

Can you define layer 7 for me, succinctly?

> > [snip repetition]

> Received on Sat Feb 24 2007 - 14:37:57 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US