> > 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 :)

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

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

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

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

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 ;-)

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

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

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

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


With regards,

Martijn Tonies