Re: Navigation question

On Feb 18, 11:17 am, "Tony D" <tonyisyour..._at_netscape.net> wrote:
> On Feb 18, 1:44 pm, "Walt" <wami..._at_verizon.net> wrote:
>
> > "Tony D" <tonyisyour..._at_netscape.net> wrote in message
>
> >news:1171648378.363589.27160_at_j27g2000cwj.googlegroups.com...
>
> > > All this talk of "nodes", and "then", and "going to" and so on -
> > > that's not what's happening. There is no "moving finger" that you
> > > guide through the database from table A to table B. You are issuing
> > > multiple independent queries with (hopefully) increasingly defined
> > > parameters. There is no connection between them, other than some
> > > shared parameters. Even in an SQL DBMS, you *cannot* "navigate" around
> > > tables.
>
> > It is possible to write Oracle applications that proceed in precisely this
> > fashion.
>
> No you can't (hierarchical queries and 'connect by' and friends
> notwithstanding).
>
> > I have seen them. They are lousy. They deliver bad performance.
> > They are hard to learn. They are difficult to modify.
>
> Navigational code has all of these attributes, and more.
>
> The bottom line is that, in an SQL database (which doesn't include
> hierarchical queries or connect by etc. etc. god I'm getting tired
> qualifying with that) you *cannot* navigate through data. What you
> *can* do is issue successive queries picking up parameters as you go.
>
> [ snips ]
>
> - Tony
> (Who is now in a determinedly good mood, having awoken his MG from its
> slumbers. Nothing anyone can say can depress me for the rest of the
> day !)

Hi Tony -- I'm hoping you are still in a good mood. I just started looking at the Caché tutorials and saw this

http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TWEB_TopFilmsQuery8

You can get a good idea of the setup at the following page and the one after it
http://platinum.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=TWEB_LinkingClasses5

This MUMPS-like example is slightly different from the more PICK-like example I gave earlier. In spite of the data being model as both objects (with the classes) and relations (with the SQL-ish query), the logical data model is specified without methods, so no one needs to launch into OO vs Relations on this one, I hope. This data model (MUMPS) pre-dates relational and OO.

Is there something problematic or bad about this form of navigation. If not, then I might finally have my answer. If so, is it bad in the same way that it is bad to specify a JOIN in an SQL statement in a problem because that means the developer has to know where the data are located, or is there something additonally problematic with navigating like this? Thanks. --dawn Received on Mon Mar 05 2007 - 06:25:53 CET