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

Bob Badour wrote:
> >My point:
> >If you program with Java, you can use our database without knowing
 anything
> >about relational systems.
>
> My point:
> If you program with Java, you can use a relational database with greater
> productivity and flexibility, and without limiting access to Java (just in
> case).

There are many researchers that have proved that mapping objects to relational databases consumes between 20 to 50% of the development work.

Scott Ambler has written an excellent paper on this theme http://www.ambysoft.com/mappingObjects.html

Object databases reduce the mapping work to zero. Accordingly you can reach higher productivity by 20 to 50%.

> >> >Relational databases map classes to tables
> >> >no matter how many unnecessary
> >> >in-between layers you invent.
> >
> >You do have objects on one side and tables somewhere on the other don't
> you?
>
> Huh? I have objects on both sides. Some in tables and some in program
> variables.

Are you trying to bring up Lee's implementation of serializing objects to columns? This is unsuitable in practice, since

- it is totally rigid. Class changes are not possible
- does not keep track of possible multiple instantiation of the same object
- needs instantiation of objects on the server side for queries
- it will not allow to reinstantiate complex object networks
- takes objects out of their context
- does not conform to any standard
- does not allow SQL queries on member fields of stored objects

Earlier you said "a value 10 always is a value 10 in a relational database". With the above approach it is not. A value 10 of a member of an object is serialized to an array of bytes.

So forget the above approach.

So we do have:

- Objects on one side
- Tables on the other
- a mapping that must happen somewhere inbetween.

> >Don't come up with the ridiculous design of storing objects in relational
> >columns as a counter-example. It is not used in practice and it provides
 no
> >sensible querying mechanism.
>
> The intelligence of practitioners is not my fault. As for querying, it
> provides the best querying mechanism. Your statement is again simply
untrue.

The querying mechanism is rigid and limited to the methods of the stored objects. Since all objects need to be instantiated for querying, the algorithm is very slow and resource consuming. Indices to improve execution can not be used.

> >With this blind decision they choose to spend 20 to 50% of their
> >implementation work on mapping objects to tables.
>
> Well, if they choose to map objects to tables, that's their first mistake.
> Object classes map to domains, dummy!

Again:
No matter how many inbetween layers there are, you have objects on one side and tables on the other.

> Actually, when dealing with relational DBMSs, arbitrary, nebulous,
> conceptual decisions are solidified into sound correct solutions using
> normalization.

Actually when dealing with a clean class design, there is no need for another representation in a different form that represents an old-fashioned paradigm. Relational databases where designed before object-oriented languages were widely adopted. No wonder they don't match.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com