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. With that kind of logic *any* database could be considered object-oriented. Hence we can just ignore the term OO DB alltogether and come up with a new one until you do the same thing to that term. RDBMs don't support "objects directly". *Of course* you can implement something that transparantly stores objects in an RDBMs, but you still don't get around the fact that the DB itself does not use those concepts. In order for one logical object to refer another, one have to use keys. In order to *traverse* those references, one has to search entire tables!

The point of using a *real* OO DB is that it natively supports OO concepts; there's no mapping involved, and performance certainly doesn't suffer because you need to do 20 joins in order to traverse an object graph with some depth!

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

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! It's the next best thing to completely automatic persistence.

---
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller_at_infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey_at_scode.org
E-Mail: peter.schuller_at_infidyne.com Web: http://www.scode.org