> Oh darn, we'll never finish this :-)
>
> (let's not start about Case Sensitive programming languages either)

No, there's nothing to discuss - myName != MyName != MYNAME :)

> 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.

> Right - we had that same issue for a company I worked for with
> Lotus Notes. Very document based.
>
> In the end, there are all sorts of "weird" situations because of
> this very same example.
>
> You can easily avoid just that with a relational based system AND
> have your documents (for that time) in a consistent manner.

Well, then it was exactly an example when people wanted to do
something without understanding the requirements. In my current
project a big company tried to use LotusNotes to manage insurance
claims. They failed because of the same reason you mean and we have
created a soltuion with OO->RDBMS mapping and it works perfectly. But
I also know very successful examples of Lotus Notes usage where
implementing the same solution with RDBMS would be quite painful.

> Who is the owner of the schoolbook after her marriage?
> "Ms Alice Firebird"
> or
> "Ms Alice Object-Firebird"

Ms Alice Firebird and Ms Alice Object-Firebird at the same time. But
having the "Ms Alice Firebird" on the schoolbook you also know that it
happened before the marriage. In order to keep the same information in
relational model you need to add that explicitly.

> Or the XML-crowd is repeating past mistakes... Dunno.

We'll see :) I know quite successful examples of using hierarchical
databases for traffic optimization and in oil-drilling prognosis.

> There's nothing natural about data storage. It's all a mapping of
> real world problems to logic that can be understood by computers.

True, but the mapping is never complete and you loose some semantical
information. So the question is what information can you sacrifice and
what you need there (also considering the implementation). This
determines the data model.

Roman