Thread: 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
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 > >
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&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.
__________________________________________________________________________