Re: Mixing OO and DB

"topmind" <topmind_at_technologist.com> wrote in message news:ddc9129c-1de0-450c-b6bd-8a8501b7bbfd_at_s8g2000prg.googlegroups.com...
> On Mar 12, 9:14 am, S Perryman <q..._at_q.com> wrote:
> > Bob Badour wrote:
> > >> Robert Martin wrote:
> > >>> That's fine. Consider, for example, an algorithm that finds the
> > >>> minimum spanning distance of a graph. (e.g. cheapest network route,
or
> > >>> cheapest travel itinerary, etc). The node and edges of the graph are
> > >>> stored in database tables.
> > >>> Shall we execute that algorithm by doing thousands of tiny queries
as
> > >>> we walk from node to node through the edges? Or shall we query all
the
> > >>> nodes and edges in one gulp, arrange them into a graph of objects,
and
> > >>> walk through them that way?
> > > If one studies the algorithms for minimum spanning trees, one quickly
> > > sees the task involves no traversals whatsoever. In fact, one
generally
> > > creates the MST as a precursor to some sort of traversal, and the
> > > algorithms themselves are specified in terms of sets, which makes them
> > > ideal for implementing relationally.
> >
> > What about the canonical graph algorithms (breadth/depth first,
transitive
> > closure etc) ??
> >
> > Traversal (accessing adjacent node sets) for these happens on a per-node
> > basis, does it not.
>
> An implementation probably will, but that does not mean that graph
> searching cannot be *defined* declaratively. In other words, a
> language may have a declarative "request" but the implementation may
> decide to use a node-per-node processing algorithm.
>

In fact, when a declarative query is transformed into a response, "what" is always transformed (invisibly) into "how". A strategy generator generates many different answer to "how", and the query optimizer picks one of them. This isn't only true in the case of graph searching. It's true in general.

If I can go back to the bad old days of 1994, the query optimizer in Oracle V7 was really lame. It did things like look at which query was mentioned last in your query in order to pick a driver table. So the real Oracle gurus learned to do things like SELECT * FROM B, A instead of SELECT * FROM A, B. Or, worse yet, they learned how to use "hints", which amounted to manual optimization.

This was a good adaptation to a bad situation. Those of us who had gotten spoiled on products with a good optimizer were treated like the "outgroup" by the Oracle gurus. But they were blinded by their adaptation to the way an RDBMS really ought to work.

Not that SQL Server or even MS Access gurus are any better. Received on Thu Mar 13 2008 - 18:20:54 CET