Re: Navigation question

From: dawn <dawnwolthuis_at_gmail.com>
Date: 25 Feb 2007 14:58:54 -0800
Message-ID: <1172444333.974143.227280_at_q2g2000cwa.googlegroups.com>


On Feb 23, 10:10 am, "Walt" <wami..._at_verizon.net> wrote:
> "dawn" <dawnwolth..._at_gmail.com> wrote in message

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

First, I'll grant that the OSI layers are not in my area of expertise, so I might very well have this wrong. I am talking specifically of the 7 layers (of protocols) identified as the "OSI layers." Given these 7 layers, I am not then talking about taking any one of these layers and further subdividiing it by protocol, but simply referring to it so that it is clear (that obviously did not work) that I'm talking about the Application Layer.

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

Surely not. Database theory is highly relevant to conceptual modeling, outside of this list of 7 layers, as well as to the interface between developer and DBMS, for example. While there are surely some here who have an interest in data in some machine-readable format that might not be all that useful for human eyes or application programmers, I'm interested in Layer 7, the Application Layer. Again, I am not bringing this in so that we can discuss protocols within that layer, simply so that it is clear I'm not talking about "physical navigation."

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

Some software within the application layer uses SQL, but it is not essential that one does, depending on the DBMS toolset.

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

I will grant that when sitting in SQL-land, we can "go" nowhere. That is why my question is about navigating databases, not about SQL or even the RM, which we can agree are separate from any form of "navigation" that might be considered an anti-pattern. Any navigation in SQL-land is physical or possibly user-navigation (conceptual), but not "logical navigation." I think mAsterdam had comments on that term that I have not yet replied to, so I'll note here that by "logical navigation" I mean that we navigate through data via appliation code and metadata, rather than by way of any physical pointers, for example.

> Whether applications should or should not navigate within their own data
> space is really not a question for database theory, is it?

Yes, I think it has cropped up many times in database theory. Each time I read about it, it seem to me that the writing is mixing logical and physical navigation, thinking, perhaps, that if we navigate within application software then we are tied to some underlying physical navigation. However, we can surely keep our logical navigation specifications (code & metadata) the same while any physical locations change.

The reason I am asking the question is that I have questions about various things I have read. I am clumping them altogether with a general question asking about why navigation is "pooh-poohed" and perhaps I need to take a specific person and their specific statements (even though I doubt many of you are suggesting that I am incorrect in thinking that navigation is frowned upon). I can read about it, but when I ask people the answers seem to be "it was long ago determined that database navigation is bad, just read the literature." But I have read some and it is not crisp enough for me. What I have read often drags physical pointers in the discussion and I want to discuss "logical navigation" and not "physical navigation."

I think, but do not know, that the final responses I'm getting on this are at least not contradictory to "Logical navigation of databases using some combination of application code, metadata, and a nonrelational  DBMS is just fine, no worse than SQL statements with JOINS. It is a design pattern with pros and cons like any other."

I plan to take mAsterdam's advice and re-read all of the responses (attempting to ignore BB's, which unfortunately can still serve to drag me down personally, in spite of my attempts to push them aside). I will also go back to some of quips (here) and earlier documents that prompted me to ask the question. I will see if I can better understand what aspects of the arguments have anything at all to do with my two database navigation examples (code navigating and DBMS navigating based on metadata specs and query declarations).

My assessment to date is still that database navigation, the way I am discussing it, is not the evil it might have been purported to be. There is always the possibility that BB is right and I am still very confused on this point, as I certainly have been in the past. Thanks for your help! --dawn Received on Sun Feb 25 2007 - 23:58:54 CET

Original text of this message