> Huh? I just see you shouting "myname" three times in an increasinly
> louder volume :-)

:))

> > > Not exactly for each entity - that depends on the design. For
> > > starters, it probably wouldn't be bad: one table/entity.
> >
> > Uhu, USER_ROMAN, USER_MARTIJN, USER_HELEN and so on :) And dynamic
> > query generation by string concatenation.
>
> Eh, I meant: table/entity-type

And I meant exactly entity instance. Some kind of a structured
query-able attachment.

> btw, I'm all "for" OO-RDBMS mappings. That's a good thing.
> (that is, if you don't have to sacrifice any DBMS constraints
> etc to get it done. The DB-design should go first).

Very often it is a bad thing. There is impedance mismatch and when
people try to navigate through relational data nothing good happens.
Or when people try to implement some relational queries on top of
objects that are persisted in relational database - nothing good happens.

> Yes. It's called "history". Try searching your document store for
> all books ever owned by Ms Alice Object-Firebird when she calls
> on the phone ;-)

If you normalize your data model and preserve information that the
schoolbook belonged exactly to Ms Alice Firebird and not that it
belongs to the Ms Alice Object-Firebird now and she was before Ms
Alice Firebird, I suspect that my query will be shorter than all your
joins.

> Do you ever drive by car or bicycle and had to stop before
> a traffic-light? Call that traffic optimization? ;-)

Probably "traffic optimization" was wrong term. I meant optimization
of the routes for logistics, e.g. what is the shortest route that
brings most profit.

> I doubt it. I think you're talking about "database design", which is
> not "the relational model".

I talk about "applying quantum theory to a cubic meter of our air".
You can try to represent everything in your database using relational
model, but it will be huge and unmaintainable.

I do not care that quantum theory allows me to describe each single
particle and having indefinite time I can model my cubic meter of air
perfectly precise.

I need to represent the information I process so that no _relevant_
information is lost, I want to spend as less time as possible and I
want my queries to be answered as fast as possible. And if XML DBMS
solves my problems, it has perfectly ok that XML DBMSes are
implemented, promoted and sold.

Roman