Re: Flamewar object databases vs. relational databases (was: Unknown SQL)

>>I disagree. Since relational supports objects directly, you still have an
 OO
>>system. In a strict and precise sense, relational is already an OODBMS.
>
>Typical catch-all phrase.

Catch-all for what? Object Classes map directly to Domains, both are user-defined types. Since Domains have been an integral part of the relational model since 1969, so have objects.

>With that kind of logic *any* database could be
>considered object-oriented.

Any database that is object-oriented is object-oriented regardless of the data model. Why do you think that network model OODBMSs are more object-oriented than any other?

>RDBMs don't support "objects directly".

SQL databases don't support objects directly. Relational DBMSs do.

>*Of course* you can implement
>something that transparantly stores objects in an RDBMs,

Actually, an RDBMS already implements that so I wouldn't have to do anything.

>but you still don't
>get around the fact that the DB itself does not use those concepts.

Your assumption here is false.

>In order
>for one logical object to refer another, one have to use keys.

Well, we could have a strict containment relationship within the domain, which would not require the use of any keys.

>In order to
>*traverse* those references, one has to search entire tables!

Even using keys, the above statement is untrue.

>The point of using a *real* OO DB is that it natively supports OO concepts;

An RDBMS does support OO concepts natively. As I said previously, an RDBMS is already an OODBMS.

>there's no mapping involved

The mapping is inherent in that domains are object classes. This mapping comes at no cost. I don't really see your point here.

>and performance certainly doesn't suffer
>because you need to do 20 joins in order to traverse an object graph with
>some depth!

Since the relational model imposes no restrictions on the physical storage of data, no reason exists for a 20 table join to cost anything if you choose to cluster your data that way.

>If you're working on huge amounts of flat data - fine, an RDBMS is probably
>faster. If you're not, it's another matter.

This statement is untrue.

>I have to admit I missed the first part of this thread, so if the
 parameters
>of the argument / flameware is different I apologize, but I persoanlly
>cannot fathom why anyone would claim that the ability to treat database
>objects like any other object is insignificant!

I don't recall anyone making that claim.

>It's the next best thing to
>completely automatic persistence.

Be careful what you wish for. You just might get it.

Regards,
Bob Received on Sun Jul 22 2001 - 01:29:18 CEST