Re: S.O.D.A. database Query API - call for comments

From: Carl Rosenberger <carl_at_db4o.com>
Date: Sat, 21 Jul 2001 18:00:40 GMT
Message-ID: <9cq8et$thj$06$1_at_news.t-online.com>


Mikito Harakiri wrote:
> >> >queries step-by-step with many small functions.
> >>
> >> Of course, it was exactly to get away from that, that SQL was
> >> invented.
> >
> >I am afraid that object-orientation was not used in those days.
>
> Robert Martin on comp.object admitted that OODBMS is no more than
> persistent storage of nested structures.

No, that is not true.
Object databases also use indices to organize data for efficient querying.

Anyway:
If I were to neglect triggers, stored procedures, constraints and other vendor-incompatible constructs that violate object business logic, I could respond:
Relational databases are no more than the persistent storage of flat tables.

Why do VARCHARs need a fixed length?
Why do you have to convert objects to strings manually to communicate with the database? Can't the database do the job for you? What is the string back-and-forth conversion good for?
Why do you need to fetch IDs after inserting records, just to join them to
other records? Can't the database do the job for you?

> begin quote >>>>>>
>
> Object Oriented databases have an unfortunate name. They aren't
> object oriented at all. Rather they are like large virtual memory
> areas. The "objects" in an OODB are really just data structures.
> Their behavior is typically not stored with them.

Behaviour is implicitly stored with objects, due to their binding to a class in the programming language. There are approaches that allow method interaction on the database side.

> Both kinds of database expose data, whereas true OO hides data and
> exposes behavior. RDBs have little or no behavior.

Where is the advantage of relational databases?

> OODBs sometimes
> pretend to have behavior (methods in the objects) but developers will
> find that as the application domain grows they will feel a pressure to
> move that behavior out of the database classes and into specific
> application classes.
>
> <<<< end quote

I can't see an argument against object databases, if they provide no less functionality than relational databases.

> If nesting is the only feature that you leverage, then the approach is
> essentially CODASYL, or even worse, hierarhical db.

As to hierarchical databases:
Are you informed about Ericssons record-breaking approach?

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com
Received on Sat Jul 21 2001 - 20:00:40 CEST

Original text of this message