[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: "Al B. Snell" <alaric@a...>
• To: Uche Ogbuji <uche.ogbuji@f...>
• Date: Wed, 23 May 2001 12:56:21 +0100 (BST)

On Tue, 22 May 2001, Uche Ogbuji wrote:

> 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.

There doesn't have to be a setback in performance, it depends on what
you're doing, as in most things. You still use joins in an ORDBMS
(object-relational, like Postgres). The main additions that ORDBMSes have
over RDBMSes are:

1) You can create compound types. Eg, define a "coordinate" as a triple
of integers, so you can refer to fields of coordinate type rather than
having to have three fields of integer type called "x,y,z". Then you can
define methods on them for linear distance between two of them, etc. This
doesn't affect the underlying database at all, really; it just allows you
to put your vector library in the database engine and refer to it in
select statements and the like, and share it between the different client
implementations.

2) Table inheritance. You have a People type, then Student and Staff types
that inherit from that. Create actual tables of Student and Staff records,
but not of People (it's abstract). The benefits are twofold: Student and
Staff automatically get the common fields from a single declared place, so
you can add new fields to both by just adding to People, and you can write
"SELECT * FROM People" as shorthand for "SELECT * FROM Student UNION
SELECT * from Staff".

> 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".

Where I work, I design relational database schemas and code side by side,
but paying attention to the fact that this is an interface; I try to
minimise the assumptions each side makes about the other...

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software  

• References:
  • Re: Picking the Tools -- Marrying processing models to data model s
    • From: Uche Ogbuji <uche.ogbuji@f...>

• Prev by Date: Re: whitespaces, need a help !
• Next by Date: beginner doubt, kindly assist
• Previous by thread: Re: Picking the Tools -- Marrying processing models to data model s
• Next by thread: Re: Picking the Tools -- Marrying processing models to data model s
• Index(es):
  • Date
  • Thread