Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newscon02.news.prodigy.com!newscon06.news.prodigy.com!prodigy.net!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!y41g2000cwy.googlegroups.com!not-for-mail
From: "Dan" <guntermann@verizon.net>
Newsgroups: comp.object,comp.databases.theory
Subject: Re: What databases have taught me
Date: 25 Jun 2006 15:29:55 -0700
Organization: http://groups.google.com
Lines: 79
Message-ID: <1151274595.524375.281480@y41g2000cwy.googlegroups.com>
References: <1151026488.310207.201890@m73g2000cwd.googlegroups.com>
   <449bbb4b$0$16574$636a55ce@news.free.fr>
   <1151065041.782870.171820@i40g2000cwc.googlegroups.com>
   <449bfb26$0$299$626a54ce@news.free.fr>
   <1151074564.700824.142260@g10g2000cwb.googlegroups.com>
   <449c0462$0$13036$626a54ce@news.free.fr>
   <1151082051.235942.108180@g10g2000cwb.googlegroups.com>
   <449c26af$0$284$626a54ce@news.free.fr>
NNTP-Posting-Host: 71.121.132.232
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1151274599 21960 127.0.0.1 (25 Jun 2006 22:29:59 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sun, 25 Jun 2006 22:29:59 +0000 (UTC)
In-Reply-To: <449c26af$0$284$626a54ce@news.free.fr>
User-Agent: G2/0.2
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Boeing Kit; .NET CLR 1.1.4322),gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: y41g2000cwy.googlegroups.com; posting-host=71.121.132.232;
   posting-account=vPtQ0wwAAAA8ORvj2qWwqbhJzlBNIbvI
Xref: dp-news.maxwell.syr.edu comp.object:140981 comp.databases.theory:42303


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 '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
> p in 'onurb@xiludom.gro'.split('@')])"