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

Chris Trathen schrieb:
>
> I'll add just one comment:
>
> I use a simple criteria: The persistence mechanism dictates what type of system
> you have, object or relational.
>
> If you use a RDBMS then you have a relational system, even if you use Smalltalk,
> Java, C++ over the top.
> If you use a pure OODBMS, then you have an OO system.
>
> No doubt there are always reasons for choosing any approach and I am not passing
> judgement. In the end the approach chosen will have advantages and
> disadvantages.
>
> Chris Trathen

 This thread is very surprising and it's always the same :-(((

 I've done projects with relational- and object-oriented databases under Smalltalk and here some points from me:

• it's clear, that OODBMS *can* be superior to RDBMS. No discussion about this !
• RDBMS are based on a query concept. OODBMS are very strong on the navigational concept (though OODBMS can do queeries ...).
• benchmarks showing a tree structure are superior on navigational systems, when they use page-server systems and object chaches.
• application are not only based on the navigational approach, database application are also based on the query approach
• BUT: *Very* often the GUI (of such an application) are based on the navigational approach and very often the application are just copies of the Windows Browser approach. This is not an ideal programming idea ...

   This GUI approach will succeed with ORDBMS, but may fail with RDBMS,    but this is a problem of the programmers ... not the system.

• when using a rdbms and an OO language noone should really do this without a framework. Using them one does NOT need 90 minutes to write the query and insert sql statements. Very often you just say "anObject save" and that's it. The framework does the rest.
• oodbms are a good way to give non-database aware programmers a persistency system.
• databases - either OODBMS or RDBMS - are very complex system and each system *will* need time to understand the system. The problems with locking, storage of native systems, garbage collection and indexing ...
• even with high-end OODBMS one can configure the database how to store my application object. This is indeed the same as changing my table layout in a relational database. (just an answer to one of Carl's points).
• OODBMS are very vendor based products, no standard viewable and this may be good for projects - but long-time solutions ???
• the generation of unique ID's are done in software and not via a database specific solution. This does not need any communication between client and server (just one access in the beginning) and is incredible fast. Sorry to say, that most programmers are not aware of such solutions.
• working with RDBMS and Smalltalk in my projects:

   : I *do* think in terms of tables and how many queries I need   to get an object.
   : I *do* think of the right ballance between query approach and   navigational approach
   : I *do* think about the problem where I need object identity      or just object equality.

   On the other hand I'm able to write little script programs with    PEARL or Python once the SQL-queries are stabled !!

 This topic is so difficult: it's sad, that we're talking in such a way about this.

 Marten Received on Mon Jun 04 2001 - 13:48:52 CEST