Re: Navigation question

On Mar 2, 6:45 pm, "Walt" <wami..._at_verizon.net> wrote:
> "Bob Badour" <bbad..._at_pei.sympatico.ca> wrote in message
>
> news:RP2Gh.4796$PV3.45488_at_ursa-nb00s0.nbnet.nb.ca...
>
> > Actually, I would say that Tony D gave the definitive answer on February
> > 16 at 1:52pm.
>
> In Google groups, I found an answer from Tony D at 12:52 PM. I assume
> that's the one.
>
> Here's an excerpt:
>
> <quote>
> Probably because you *can't* "navigate" around an SQL database

Please look at my example again. I am saying nothing about an SQL database. Does my example navigate a database?

> in the
> way you would navigate in a car. There are no predetermined routes
> that you must follow;

I agree that the routes are not specified in a relational database implementation (or approximation thereof). We specify the joins with each new query or with their underlying views. Developers specify the same join information repeatedly, strewn throughout code, rather than retaining such information in the metadata repository (catalog) for reuse, excpet with the occasional SQL view. There are tradeoffs, of course, but there is a general lack of agility in making some types of changes when taking this approach.

So, yes, instead of navigating with a map already drawn, you end up cutting a path, unable to see if anyone else has cut the same path before you.

That means that the roads are not there, but we are still navigating, as in going from our house to grandma's house, if we do something like taking the grandmaAddressId value from one query and using it to find the city from the Address table. If the first query and the second could be done together, then there is only one SQL query and there is no navigation. Within a single SQL statement, there is no logical navigation.

So I agree that instead of the DBMS having these "predetermined routes" each developer needs to figure them out and recode them. However, I do not see how this would not be navigation, it is simply not navigating with a map (maybe it's the way men navigate, finding their way around without the roads already on the map, where I prefer to have the map laid out in advance).

> you can join tables using whichever columns you
> like, and leave the DBMS to worry about how it will be done. If you
> really must persist with a car driving metaphor, consider the DBMS as
> your taxi driver and the query optimizer his GPS.

except that in the case of an SQL query, I am not talking about the query itself "doing" any navigation, just participating in it. In the example of SQL (which is not my primary example -- the one I gave in my last post is), the database navigation I used as an exampe is when a result from one query is used to navigate to other data by the developer.

> You ask him to take
> you to the store, but you don't sit behind him telling him when to
> take a left.
> <end quote>
>
> Dawn, this probably is the definitive answer. You need to understand this
> response,

I think that I fully understand how a single SQL statement is not a statement of navigation. I do not yet know if my two examples, the one being non-SQL and the other SQL, are accepted as "database navigation", which they sure seem to be and whether they are acceptable design patterns for software development or are clumped into the often heard statements against database navigation.

> and demonstrate an understanding, before I'm going to invest any more time
> in trying to discuss this with you.

How am I doing?

>
> > >>(that is, I don't care if it sequentially reads
> > >>the entire medium multiple times at the physical layer, but to the
> > >>developer the database is navigated). If no one can give an example
> > >>of bad navigation (at the logical level), then could someone at least
> > >>tell if either or both of the examples I have provided for navigation
> > >>are bad and, if so, why.
>
> > > If there is no navigation at the logical level, then there is no bad
> > > navigation at the logical level.
>
> > >>I very much appreciate any effort given to try to help me understand
> > >>more precisely what database navigation is considered bad and why.
>
> > What a lying sack of shit. Anyone with half a brain can see she has no
> > fucking intention of every understanding a goddam thing and she never had.

If others would be willing to address the language in this ng, I would be most appreciative. This is very offensive, both for its inaccuracy and slander, but also for the language.

I really do want to understand this. That is not the same thing as saying that I am willing to convert to some system that believes that database navigation is bad without any proof. I would very much like to understand precisely what navigation is bad. I do not yet know if my two examples (one SQL and one not) are examples of bad database navigation or acceptable database navigation. I am particularly interested in the non-SQL example I gave in the my last posting and many prior ones.

These database navigation design patterns (in my examples) are very prevelent in software development, but have a cloud hanging over them because there seems to be some general acceptance that database navigation is a bad thing. I don't grok it yet and I want to. Thanks. --dawn

> > > Address based access.
>
> > Why, oh why, must you feed the troll? Do you do it to annoy everyone else?

I do not wish to be a troll anywhere. If this were a "relational database theory newsgroup" then my questions would be troll-like. But it is not and my questions are not. They are honest attempts to understand. --dawn Received on Sat Mar 03 2007 - 05:50:30 CET