Re: Navigation question

On Feb 23, 2:19 pm, mAsterdam <mAster..._at_vrijdag.org> 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?

>
> >> 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 ...

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. 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?

> >> 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. 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.

This is where we can query Person and request the mother's name for a person with a particular ID. The DBMS has the navigation metadata and can, therefore, navigate from a child's tuple to a mother's tuple, retrieving the name. Using a non-SQL language available in a real DBMS, the query might be
list People name motherName with _at_ID = "77777"

2. Application software navigates by issuing a query and then using a value from the results of this query to seed another, such as taking a foreign key value from one relation to retrieve information from another in a subsequent query.

I have re-read many of the responses and I'm not yet finding the answer. These seem to me to be acceptable patterns, requiring the same wisdom when choosing them as any patterns do. But when people talk about navigation being bad, it seems that they often mean one or both of the above. Thanks for any help getting to clear answers on these. Thanks. --dawn Received on Fri Feb 23 2007 - 22:07:38 CET