Re: Navigation question

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news: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."

Could you list the layers, and give a link to a web page that describes them?

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

Two responses:

First, fair enough. But I think it's also correct for you to modify your original comment regarding Codd, Date, and Pascal "frowning on navigation" to apply to "navigation within the database". Any navigation a programmer does entirely within the application is not relevant to the comments Cdd, Date, and Pascal have made regarding database data.

Conceptual modeling of data is not necessarily directly relevant to database theory.
Conceptual modeling of data is directly relvant to data management. Database theory (and practice) is directly relevant to data management. So, indirectly, conceptual modeling of data and database theory will be relevant to each other. But it's useful to be explicit about data management as the bridge between them.

>
> > 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 non-
> relational 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 Mon Feb 26 2007 - 15:28:18 CET