RE: OODBMS vs. RDBMS - Mailing list pgsql-general

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I have spent the last eight months working with a commercial OODBMS,
and I'm not exactly thrilled with it.  From the developers
perspective, it helps reduce the work involved in the impedance
mismatch, but for your troubles, you get locked into a particular
vendor, because the query methods are pretty proprietary, as are the
access methods.  There is a rudimentary form of OQL available, but
it's a pain, and even more so if you're using Java, and the DBs Java
libraries.  Also, EJB support is a pain.  As far as the
under-the-hood mechanics of data querying goes, from what I can make
out, it's not that dissimilar from a relational database to search
over a number of related entities, but where it does gain in
performance is when you start dereferencing rows (i.e.: following
relationships).  OODBs normally implement specialised relationship
mechanisms, which are faster than using primary keys.  Basically, an
abstracted pointer to the row is used (abstracted in order to enable
replication).  There are a number of techniques available for doing
this (which might bear looking into).  Having said that, though, I'm
not sure how much of a performance gain there is.  I've yet to see
numbers.  From what I can tell, OODB vendors have been successful
only in online client/server applications where the schema and the
volumes are large (e.g.: CRM), and only where they have been heavily
involved in consulting to the customer.  So, I have my doubts as to
their wider (commodity) applicability, because your average web site
doesn't have a few tens or hundreds of thousands to throw at the DB
design and related consulting.  Relational skills are still a
commodity, and if you want straight persistence, then grab a
persistence library.

Mechanically, OODBs are relational DBs on steroids with fancy client
libraries.  They have specialised persistence managers, and an
additional access method for relationships.  They also have slick
client libraries that integrate well with Java (and, to an extent,
with C++ and Smalltalk), automatically create new 'tables' when new
classes are instantiated (some hokum in the class constructor), and
manage the changes to a class automatically (some more hokum in the
constructor).  However, most of the marketing blurb seems to be
related to the client library part (i.e.: easier development) more
than the actual server part (OO data storage).  And this can be done
with relational as well as OO DBs.

The bottom line is: I don't see the added value.  Whatever gain there
is gets offset by other losses, especially when I can largely
mitigate the impedance mismatch by using something like Postgres.

Cheers...

MikeA

>> -----Original Message-----
>> From: Dave Cramer [mailto:Dave@micro-automation.net]
>> Sent: 05 May 2001 19:53
>> To: Bruce Momjian; PostgreSQL-general
>> Subject: Re: [GENERAL] OODBMS vs. RDBMS
>>
>>
>> Certainly an interesting article. Alot of negative comments
>> about existing
>> OODBMS. Personally I have been using a persistence layer to
>> acheive similiar
>> results on top of postgres. The main drawback is the speed
>> degradation
>> imposed by the persistence layer. The upside is that I have
>> direct mapping
>> into the db, and still maintain SQL compliance for all sorts of
>> adhoc queries.
>>
>> I am intrigued by the notion of an OODBM however. Does
>> anyone know how they
>> do searches, etc. How efficient this is? I realize postgres
>> has the ability
>> to store an object directly into the db, but how would you
>> implement a
>> search, on an attribute of the object, or do multiple index's etc.
>>
>> Dave
>>
>> ----- Original Message -----
>> From: "Bruce Momjian" <pgman@candle.pha.pa.us>
>> To: "PostgreSQL-general" <pgsql-general@postgreSQL.org>
>> Sent: Friday, May 04, 2001 2:38 PM
>> Subject: [GENERAL] OODBMS vs. RDBMS
>>
>>
>> > There is a Slashdot article and discussion about OO database vs.
>> > relational databases.  They mentioned OID right at the
>> > beginning.
>> >
>> > They guy mentions six advantages of OO databases and only one
>> > disadvantage, but it is an interesting read to see how the
>> PostgreSQL
>> > features match some of the OO features.
>> >
>> > The main argument is that mapping relational tuples into
>> object-oriented
>> > classed in your application is a pain:
>> >
>> > http://slashdot.org/article.pl?sid=01/05/03/1434242&mode=nested
>> >
>> > --
>> >   Bruce Momjian                        |
>> > http://candle.pha.pa.us
>> >   pgman@candle.pha.pa.us               |  (610) 853-3000
>> >   +  If your life is a hard drive,     |  830 Blythe Avenue
>> >   +  Christ can be your backup.        |  Drexel Hill,
>> Pennsylvania 19026
>> >
>> > ---------------------------(end of
>> broadcast)---------------------------
>> > TIP 4: Don't 'kill -9' the postmaster
>> >
>> >
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 1: subscribe and unsubscribe commands go to
>> majordomo@postgresql.org
>>

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOve5wnympNV/C086EQKBuwCgnMEfOgrdyJedE1pD/uMc04y+3QkAnRf8
D0wLiXK23YbRCI10M1l9mvaK
=SKiK
-----END PGP SIGNATURE-----

_________________________________________________________________________
This e-mail and any attachments are confidential and may also be privileged and/or copyright
material of Intec Telecom Systems PLC (or its affiliated companies). If you are not an
intended or authorised recipient of this e-mail or have received it in error, please delete
it immediately and notify the sender by e-mail. In such a case, reading, reproducing,
printing or further dissemination of this e-mail is strictly prohibited and may be unlawful.
Intec Telecom Systems PLC. does not represent or warrant that an attachment hereto is free
from computer viruses or other defects. The opinions expressed in this e-mail and any
attachments may be those of the author and are not necessarily those of Intec Telecom
Systems PLC.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
__________________________________________________________________________