Re: Navigation question

On Feb 21, 9:16 am, "Walt" <wami..._at_verizon.net> wrote:
> "dawn" <dawnwolth..._at_gmail.com> wrote in message
>
> news:1172066290.728188.161780_at_q2g2000cwa.googlegroups.com...
>
>
>
> > On Feb 21, 2:01 am, mAsterdam <mAster..._at_vrijdag.org> wrote:
> > > dawn wrote:
> > > > In another thread "navigation" is again mentioned as undesirable.
>
> > > Navigation is from here to there.
> > > Things like distance, direction, movement, traveling time, location,
> > > path and space are relevant concepts.
>
> > > In RM the database (at the logical level(*)) is a single-point
> > > thing. No navigational term has any meaning in a
> > > single point. Conversely, non of the RM terms
> > > have any navigational meaning.
>
> > Agreed. So, this discussion about navigation is outside of the RM.
>
> > > (*) Some may maintain that the RM covers no other level.
> > > A lower, physical level is implied, and AFAIK most
> > > book that cover RM also touch it. A lot of
> > > navigation is going on at that level. Without further
> > > qualification, every navigational remark is, by default
> > > about that level, the physical level.
>
> > > Nothing good, nothing bad here, just: navigation is something that
> > > does not exist within the RM.
>
> > Right. I do not know if navigation is often spoken ill of in this
> > forum 1) because it is outside of the RM 2) for the same reasons that
> > it is outside of the RM, whatever those might be or 3) for other
> > reasons. I'm trying to understand what about database navigation is
> > considered "bad" and why.
>
> You've got it backwards, Dawn.
>
> The defects of user specified navigation were discovered first,

Yes, defects as in "cons" in the "pros and cons of this algorithm" were determined. The one of which I am aware and that I can apply to my above example is that the application (algorithms plus any metadata specified for a "link", perhaps) has a "hard-coded path" in the code. This path logic holds the same information and has the same downside as if there were a JOIN clause in an SQL statement, as best I can tell.

Are there other cons to navigating in addition to the cons that are also associated with coding JOINS in an application?

> and the
> application of the RM to the problem of alrge shared data banks was
> developed in order to overcome these defects.

Yup, understood. Did it accomplish that in practice? In other words...

If we list the pros and cons of navigating from a child to a parent tuple (see response to mAsterdam if that is confusing)

within an application including app code, the DBMS, and DBMS specs such as metadata (previous example given was a DBMS that could handle something like "select customerId, customerName, emailAddresses, classifiers, Order.orderid, Order, orderPrice from Customer where tin='xyz';")

what cons are on that list? Are these cons alleviated by the RM? In theory? In practice?

Thanks. --dawn Received on Fri Feb 23 2007 - 03:23:44 CET