Re: Xquery might have some things right
Date: Wed, 24 Mar 2004 15:14:07 GMT
Message-ID: <3Bh8c.28405$_W4.4950_at_newssvr31.news.prodigy.com>
"Dawn M. Wolthuis" <dwolt_at_iserv.net> wrote in message
news:6db906b2.0403232015.2b334c4_at_posting.google.com...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
news:<rIX7c.62404$a12.2807_at_newssvr33.news.prodigy.com>...
> > "Tony" <andrewst_at_onetel.net.uk> wrote in message
> > news:c0e3f26e.0403230201.7fb37da7_at_posting.google.com...
> > > dwolt_at_iserv.net (Dawn M. Wolthuis) wrote in message
> > news:<6db906b2.0403221645.1141ecf6_at_posting.google.com>...
> > > > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> > news:<9JC7c.62219$lV6.25494_at_newssvr33.news.prodigy.com>...
> > > > > "Joe "Nuke Me Xemu" Foster" <joe_at_bftsi0.UUCP> wrote in message
> > > > > news:1079920954.616425_at_news-1.nethere.net...
> > > > > > "Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message
> > <news:3z32c.18$zW4.150_at_news.oracle.com>...
> > > > > >
> <snip> > >
> > > > What is the theory on which we base "our" disdain for navigation?
Is
> > > > the only rationale performance?
> >
> > No, it's just another manifestation of the (admittedly vague) what/how
> > distinction. We should, at this point in the history of computing, be
> > specifying WHAT we want, not how to get it. It's as if the (necessary)
> > operational thinking that dominated the design of processors now
dominates
> > everything we do, rather than allowing us to return to "pure" logic,
where
> > we can actually achieve conceptual traction.
> > What we do might be described, in theory, not as a "how to" as a > graph-theory navigation of a di-graph, just as it might be described > as a set-theory operation, right? Either way, it is the application > of a function/operation.
It could be, but you can also fall back to the Turing Machine argument and the fact that it's all just bits anyway, so why not use them directly? Graph theory is very complicated, and while it's certainly no more or less "correct" than set theory, I'd wager that the latter is more useful: tractable, automatable, and amenable to reason.
Besides that, set theory (and relations specifically) allow better abstraction for data - specifically, the node structure no longer has an effect on "finding" something, and the "nodes" can be associated closely with predicates in the problem domain.
I think there are probably many more, but that's a start...
> Neither the end-user nor the programmer > needs to do this navigation -- the vocabularly made visible in the > metadata could include virtual "fields" that are derived via > navigation -- but only the specification/definiton of that vocabularly > needs to have the "how" spec.
So with these virtual fields, you have to define not only the graph structures, but also the "meaningful" superimposition of a vocabulary on top of the graph structure, then finally the application logic on top of that vocabulary. Then you have to change the implementation of the vocabulary whenever the graph structure changes.
An RDBMS, in effect, uses whatever graphs or other data structures it wants (see Transrelational, for example), raising the level of abstraction for developers in a way that doesn't lose anything.
> Do you agree there is nothing purer or truer about a set-theorectical > operation than a graph-theory navigation? thanks. --dawn
I agree. It's just more complex and fragile, and less useful.
- erk