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.