Thread: OO and RDBMS

OO and RDBMS

From
Shridhar Daithankar
Date:
Hi,

http://developers.slashdot.org/developers/03/09/23/2016224.shtml?tid=126&tid=156

I am sure people must have seen this story. Just posting for archives..

  Shridhar



Re: OO and RDBMS

From
"Merlin Moncure"
Date:
Shridhar Daithankar wrote:
Hi,

>http://developers.slashdot.org/developers/03/09/23/2016224.shtml?tid=12
6&tid=156
>I am sure people must have seen this story. Just posting for archives..

As a follower of the advocacy list, I feel compelled to make a few
observations about the above post.  Perhaps I'm speaking to the choir,
but I am passionate about this subject, and I always astounded about the
sheer volumn of misinformation that abounds!

Every once in a while, a post of this nature appears on Slashdot.  I
haven't like at the Prevayler project recently, but as I understand it,
it is more of a supped up object streamer than a database.  These
projects and the ideas that drive them are fueled by college students
who overdosed on OO theory in college and try to fit information into
their carefully defined view.  XML has similar issues.   OO streaming
and XML have real applications, but IMO are absolutely no threat to
'Relational' Databases in the business world.  While OO is a useful and
interesting branch of programming, its application is orthogonal to
database principles and information storage.  True and correct
information storage is based on logic, not on efficient language
bindings.  Since stored data is really just information, or more
technically, a sum of all constraints, it can describe anything,
including 'objects'.

This is nothing new.  In Microsoft's .net platform, I can use the built
in serializers to stream objects to XML with very little programming.
With some XSLT and some more programming, a general approach could be
used with some features (i.e. querying) of a crude DBMS.  While the
performance can be stellar for writing and reading (Microsoft's XML
serializer can a achieve 10 mb/sec output on cheap hardware),
concurrency is a nightmare and scalability is worse.  While this seems
attractive to OO programmers who are put off by brokering objects in and
out of a non OO storage, any type of useful data mining with this
approach is realistically impossible.  Even with infinite computer
resources, the weakly defined logical model of serialized objects
contrasts unfavorably to the SQL model (and SQL contrasts unfavorably to
the relational model, but I'm nitpicking!).

Imagine database objects serialized to XML and stored in Postgres as
blob objects (but without mvcc and atomicity) and you have something
similar to Prevayler.  Obviously, since you cant make a useful index out
of a blob object, ad hoc queries are impossible unless you introduce a
'meta parsing' stage for indexing, relating (such as it is) and
performance optimization -- now destroying the 'generalness' of the
storage.  In SQL, all you have to do is type in 'create index', what
sane db administrator wants to give that up?

Generally, Postgres is more suitable in business environment in almost
every way, but the common misunderstandings about databases (urban
myths?) in the IT industry are so widespread that newcomers to the field
must have terrible trouble getting correct information.

Regards,
Merlin

Re: OO and RDBMS

From
Christopher Browne
Date:
merlin.moncure@rcsonline.com ("Merlin Moncure") writes:
> As a follower of the advocacy list, I feel compelled to make a few
> observations about the above post.  Perhaps I'm speaking to the choir,
> but I am passionate about this subject, and I always astounded about the
> sheer volumn of misinformation that abounds!

I browsed the Purveyor posts on /., and there certainly were some good
comments made.

There are several drawbacks to the would-be-superior system

 - It only provides fairly weak transactional "guarantees."

   Yes, any one transaction can can be rolled back, but it does
   not appear to extend past that.  Which is fine for a single
   user system, but not for multiuser.

 - It doesn't do anything about managing domain typing.

   The increasing support in PG7.4 for CREATE DOMAIN is something that
   should surely be trumpeted as a strengthening of relational
   modelling.  Purveyor...  Doesn't do this...

 - One of the most significant merits of the relational model is that
   it allows data access paths that weren't necessarily planned for.

   If I need to look at all the transaction records generated between
   March 10th and April 15th, that have some other oddball
   characteristics, I need only /describe/ the query, and a relational
   system can do the query.  It may not be particularly efficient in
   the absence of a useful index, but that may well not matter.

   In contrast, "object systems" are by and large a throwback to the
   Network model, where queries require writing a program to navigate
   through the paths provided by the indices.  Which is _blazingly_
   fast, if the pre-planned paths are the ones you wanted.  But if you
   need something "oddball," the result may be a query program that is
   both inscrutable and slow.

What is unfortunate is that it looks like they have implemented
something that's pretty neat that is probably pretty useful for
embedding a sort of "database" support into applications in some
dynamic languages.  But since they _dramatically_ oversell it,
apparently because the producers are "youths" that don't have enough
perspective to grasp that other systems _do_ have merits, it's likely
to get treated as worthless because of the over-sell.
--
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;