Re: Navigation question
Date: 28 Feb 2007 04:46:21 -0800
Message-ID: <1172666781.609148.240850_at_m58g2000cwm.googlegroups.com>
On 27 Feb, 20:14, "dawn" <dawnwolth..._at_gmail.com> wrote:
> On Feb 27, 8:58 am, "Walt" <wami..._at_verizon.net> wrote:
>
>
>
> > "dawn" <dawnwolth..._at_gmail.com> wrote in message
>
> >news:1172534823.070193.104950_at_k78g2000cwa.googlegroups.com...
>
> > > Walt wrote:
> > > > "dawn" <dawnwolth..._at_gmail.com> wrote in message
> > > >news:1172505529.681070.131640_at_q2g2000cwa.googlegroups.com...
> > > > > On Feb 26, 8:28 am, "Walt" <wami..._at_verizon.net> wrote:
> > > > > > "dawn" <dawnwolth..._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?
>
> > > > > I just did a google and I'm not sure whether you had trouble finding a
> > > > > link or if this is a test to see which link I would choose. We can
> > > > > start withhttp://en.wikipedia.org/wiki/OSI_model
>
> > > > I know how to google. I wanted to see what page you were reading from,
> > so
> > > > that we could read from the same page.
>
> > > Perhaps I should have been reading from a page.
>
> > > > The page you pointed me to is a good starting place. So you are talking
> > > > about protocols.
>
> > > No, I'm talking about layers and not specifically about the interfaces
> > > between them (protocols). I'm talking about that which takes place
> > > within the application layer, using the OSI terminology only to try to
> > > get the focus within the app layer, rather than below it. If the use
> > > of the OSI layers was distracting, then simply zero in on application
> > > software development, including all software (code, metadata,
> > > database, DBMS specs of any kind) that run or serve as input to
> > > executables running on top of an OS, for example.
>
> > > > > If I had been quizzed, I would have gotten the top, the bottom, and a
> > > > > few others by name, but I have never studied nor memorized these
> > > > > layers. I only referred to them in order to get the focus of the
> > > > > question on the application layer.
>
> > > > > > > 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.
>
> > > > I don't understand the above. "Surely not" what? Do you mean "Surely
> > not
> > > > limited to areas where data is exchanged in some sort of formal
> > protocol"?
> > > > If that's the case, why did you refer to "the OSI Layers"?
>
> > > I hope I explained that satisfactorily. Since it is getting in the
> > > way, rather than helping, ignore OSI and focus on application software
> > > and the development thereof, including specification for and
> > > instructions to a DBMS, for example.
>
> > > > 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."
>
> > > > If you are not talking about protocols, then why are the OSI layers
> > > > relevant to your discussion?
>
> > > > I'm terribly confused by what you have written.
>
> > > > > strictly DBMS navigation). BTW, I didn't mention Pascal. I included
> > > > > JOG as the third.
>
> > > > Noted.
>
> > > > > > Any navigation a programmer
> > > > > > does entirely within the application is not relevant to the comments
> > > > Cdd,
> > > > > > Date, and Pascal have made regarding database data.
>
> > > > > Really? I thought they were opposed to "database navigation" in
> > > > > general, whether the application is navigating its way through the
> > > > > data or the DBMS is, or some combination. Hmmm. Perhaps one
> > > > > difficulty with the terms is that I consider DBMS specifications
> > > > > related to any application suite to be "part of" that application
> > > > > suite.
>
> > > Did this clarify at all? Thanks. --dawn
>
> > It clarified a little, but I'm still confused. You can in fact divide
> > things into "layers" without regard to protocols, and the phrase
> > "application layer" means something to me. However, your reference to the
> > OSI layers suggested a common interpretation (between you and me) of the
> > term "application layer", and you are using the phrase to convey something
> > a little different than the OSI people intended.
>
> > Let's distinguish between "database data" and "application data". Data can
> > exist in a database, in "working storage" (to use an old COBOL term), and
> > be exchange across the interface.
>
> > Whether you navigate in working storage or not is entirely beside the point
> > that Codd, Date, and JOG have made, if I understand that point at all. The
> > point about user navigation interfering with both independence and
> > optimization within the DBMS is about the navigation of database data.
>
> > And, just in case, "database data" does *not* refer to copies of database
> > data in working storage.
>
> Agreed, so we are talking about "logical navigation" of a database by
> way of DBMS processes, metadata specified to the DBMS (such as foreign
> key & target declarations), and application code. The DBMS and other
> code might very well work in layers below the application layer at run-
> time, but all specifications for this navigation are done in the
> application layer. Under the app layer, the database need not be
> navigated, I don't care about that, but the navigation of the database
> takes place by way of specs that indicate that addressId is a foreign
> key in the Person relation that "points to" the addressId in the
> Address relation. Then a query can be made such as
>
> select lastName, Address.city from Person;
>
> This, from my perspective, is "logical navigation" where the developer
> is specifying that the DBMS can "get to" the Address information from
> the Person information following a certain "path" (the link
> specification), then further specifying in some chunk of code that
> what needs to be retrieved related to the Person is their lastName and
> the city, which we know to be in Address.
>
> I recognize the beauty of
>
> select lastName, city from Person;
>
> which can also be accomplished with a virtual field in the Person
> relation that logically "goes to" the Address relation to retrieve the
> city. So, this looks less like navigation in the query statement, but
> in the specifications to the DBMS (the virtual field) a path is
> presented.
>
> This can obviously also be accomplished with a vew so that we have
>
> select lastName, city from PersonAddrView;
>
> But in most code against an SQL-DBMS it is accomplished with a JOIN
> statement, which serves the same purpose as the "navigational" link
> information except that the JOIN data are repeated (considerable
> redundancy) and are spread around throughout the code rather than
> having a single specification.
>
> So, does the navigation above sound like what Codd etc think to be a
> bad thing?
Yes. You have now created an Address object. To navigate you need locations and objects give you that. Perhaps your Address object has a house object inside it, with a number object and street object too, or whatever you might want to hide away in your chain of russian dolls.
> I know that there are people who have been taught that it
> is a bad thing (I have to repair this when I hire them).
Good grief. It never ends. What price a single thread, nay just one post, without this sort of baiting. A post just in the name of discussing theory and not trying to goad people? I find this very sad : (
> I would like for there to be a clearer statement on navigation
> -- particularly,whether the above is within the scope of the seeming disdain for
> navigation or outside of it
"disdain"? Pffft. Purple prose to emote reactions. Its just not that exciting i'm afraid - opinion is just that declarative approaches are preferable to navigation, nothing more.
> and just what "logical" database navigation is wrong and why.
>
> Thanks for your help and patience with me. --dawn
I find myself more and more just posting to balance opinion for neutral readers. I have given up trying to convince you of anything - you appear too entrenched in your anti-RM crusade to be pragmatic and recognize the good points that the evolution to RM has to offer, or to see why it has been so successful despite its flaws :( Received on Wed Feb 28 2007 - 13:46:21 CET