[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

  • From: Uche Ogbuji <uche.ogbuji@f...>
  • To: Al Snell <alaric@a...>
  • Date: Tue, 22 May 2001 10:57:17 -0600 (MDT)

data models rdbms
> 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@f...               +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



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.