Re: Picking the Tools -- Marrying processing models to data model s

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

> On Mon, 21 May 2001, Uche Ogbuji wrote:
>
> > OO was about making the operations actually intrinsic to the bundles
of
> > data.
> >
> > The post-OO evolution at which I think you hinted is about flipping it
> > all the way around so we're drafting neat functions to operate against
> > the properly considered data models.
>
> That's a backwards step - databases started with that kind of
> architecture, and are trying to move to an OO model (limited somewhat by
> the lack of a decent standard)

Have you considered that it might be DBMSes taking a backward step?  That
the effort to add OO as a buzzword is lean on technical merits?

I've spent some time with object-relational features in DB2, Oracle and
Postgres, and I've perused as much of SQL-99 as I could without succumbing
to the resulting headache.  The object features do add some more
expressivity, but not enough, IMO, to justify the set-back in performance
and model transparency.

If you need RDBMS, then usually you need RDBMS.  The relational calculus
is even less expressive than OO, but it works very well if you can fit in
its domain.

I should note that one of the most important features of so-called ORDBMS
systems: UDF packaging, is probably much more "post-OO" than OO.

> > maintenance.  A trememdous side-effect of XML adoption is that it's
> > encouraging developers to finally start putting these matters in the
> > right order.
>
> How is this different from the days of SQL databases?

There was actually a brief time when this was in fact the case: when the
orthodoxy was that you thoroughly designed and normalized the data in
relational form and then used the resulting model as the basis of the
manipulating code.  I think the architecture of SQL-C is a good example:
the query host variables became the modular structures of the C code.

Unfortunately, in my experience, as OO boomed, much of this orthodoxy was
tossed out.  Not I routinely see programmer teams do their functional
analysis and then throw the result over the wall for DBAs to sort out.
"If you have to normalize this and that, don't worry, just write a few
stored procs to set it all up the way we need it".

I think strong evidence of this influence is the very tendency you bring
up for vendord to shoe-horn OO features into RDBMS.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python