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

At 02:38 PM 5/4/01 -0400, Bruce Momjian wrote:

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:

Yeah they called that "impedance mismatch" or something.

The "only" (yeah right) disadvantage cited in the article was "changing the
schema often means a system-wide recompile". Whoopee.

But one man's "impedance mismatch" is sometimes another man's "layer of
abstraction" (not always of course :) ).

When it's hard to see where the DB objects begin and the app objects end,
then there's no interface ( which can be good, or can be bad).

Having it all seamless often means you can't break things off neatly and
stick something else on. Or have lots of different things connecting using
the same "interface" at the same time. How do you get nonOO programs to
talk to an OODBMS? C or even ASM?

I'm using a Postgresql database for an Intranet. Even the telnet gateway
proxy I hacked together in Perl uses the same user names and passphrases as
those for the web applications. How would that be done if it's an OODBMS?

Is it possible and useful to have an OODBMS with a layer of abstraction? My
gut feel is yes, but I'm way beyond my scope of expertise here :).

Cheerio,
Link.

-----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&amp;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&gt;

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