Re: What databases have taught me

From: Dan <guntermann_at_verizon.net>
Date: 25 Jun 2006 15:29:55 -0700
Message-ID: <1151274595.524375.281480_at_y41g2000cwy.googlegroups.com>


Bruno Desthuilliers wrote:
> Marshall wrote:
> > Bruno Desthuilliers wrote:
> >
> >>>Yes, but SQL DBMSs are not R DBMSs.
> >>

<snip>

> > and we do not limit ourselves, (or sometimes, even concern ourselves)
> > with what products are out there today. Our concern is for theory,
> > and for what is possible. This is not to deny the existence of
> > practical concerns; rather it is to deny the exclusivity of practical
> > concerns.
>
> <trolling-again>
> but given that most comp.object readers are primarily concerned with
> practical stuff, isn't it a bit unfair to argue about the superiority of
> the relational model over OO when there's no working, usable
> implementation of the relational model ?-)
> </trolling-again>
>
> Sorry, nitpicking here - don't waste your time answering to this.
>
> > In *theory* you just use the transitive closure operation. Does
> > this help you solve your practical problem today? Sorry, no.

We use them now, in real world life, such as breaking down the bill of materials for airplanes.

>
> Too bad.
>
> > (However, you may wish to check if the database product
> > you use does support some kind of transitive closure operation,
> > such as Oracle's CONNECT BY.)
>
> I'd prefer to stick to SQL standard as much as possible. I have a need
> for solutions that can run on as many SQL DBMS as possible.
>

There are quite a few DBMS products that offer the transitive closure operation. Teradata has the WITH RECURSIVE statement. DB2 has a similar transitive closure syntax, both coming somewhat close to a standard SQL sytanx. Oracle still uses the CONNECT BY, which is unfortunate, but merely implies a translation exercise when trying "swap out" DBMS support, if that is really a super important reason to some.

Swapping "persistence engines" might be a big thing for some, but I would prefer to see the transitive closure operation actually performed right and consistently, and I certainly haven't seen such implemented systematically (i.e. consistent) with OO procedural code.

"Persistence engines" already exist in the form of VERSANT, Gemstone, Poet (now versant), etc. many of which that once claimed themselves DBMS's, but that now sell themselves as middleware transparent persistence engines. These persistence engines are not necessarily DBMSs, so from a practical standpoint, the market has already made the distinction between good data management systems and persistent storage mechanisms.

Moreover, since constraints and data management services provided by the SQL DBMS offer greater assurances that identity from the business's domain of discourse will be represented with a degree of fidelity rather than a general low-level system's level identity artifact that is navigational in nature and often carries the baggage of identifying things from an application gui identity approach, one can write multiple transitive closure operations over the same business domain from many different access points, and thus can ask and answer questions using names users use, over both graphs and hierarchies without getting inconsistent results.

  • Dan
    > --
    > bruno desthuilliers
    > python -c "print '_at_'.join(['.'.join([w[::-1] for w in p.split('.')]) for
    > p in 'onurb_at_xiludom.gro'.split('@')])"
Received on Mon Jun 26 2006 - 00:29:55 CEST

Original text of this message