Oh darn, we'll never finish this :-)

(let's not start about Case Sensitive programming languages either)

> > If the blob holds a single value (eg: "movie"), why is it wrong?
>
> And you want to deprecate
>
> SELECT * FROM myTable WHERE movieTypeUDF(myBlobColumn, 'AVI')
>
> queries?

Hmmm - in the ideal relational sense, I think there's a table for
each type of movie :-)

> > There are plenty of systems with hundreds or thousands of
> > tables. If this is what it takes to guarantee data consistency,
> > fine with me.
>
> No, but you do not define a table on per entity basis, i.e. for each
> new entity new table. Do you?

Not exactly for each entity - that depends on the design. For
starters, it probably wouldn't be bad: one table/entity.

> > The problem I see with XML as a single entity and operators
> > to query/massage its value, is that in the examples given, it
> > doesn't make sense at all.
> >
> > It duplicates data, it puts a burden on consistency etc etc...
> >
> > Take the example from earlier on -- it had books and authors
> > and you can store "Published" with it as well, right?
> > Now what happens if the publisher changes name? You have
> > to go through all (or let the XML-DBMS do it) to change all
> > values (of type "XML") and look for a certain node...
>
> Wrong. I do not update publisher there. Because at the time when book
> was published the publisher had an old name. You just do not update
> that document - document is perfectly consistent and its contents is
> correct.

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.

> If a girl marries somebody and changes her surname, she does not start
> to change her maiden-name on all her schoolbooks, does she?

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

> > Sounds messy.
>
> If you try to apply relational point of view to XML model - yes. That
> only means you don't understand it correctly. Same as people that have
> learned structured programming are doing their first stept in
> object-oriented world. They simply think wrong.
>
> > People might want to rethink if storing complete documents is the
> > "way to go". It's not like we have come up with some silly
> > requirement the last 2, 3 or 4 years that suddenly makes it
> > impossible to store data into a relational based DBMS. What is
> > happening here, is that people invent a new query language to work
> > around problems: multi value stuff in a single "value" (namely: the
> > XML document).
>
> Wrong. People just want to work with the documents in a natural way
> they are used to. They want to add semi-structured notes to the
> documents and want to be able to query that documents. That does not
> really fit the relational model, and you want them to restrict with it.

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

> > > I meant relationships like grandfather-grandchild. You do not have
> > > explicit relation using some surrogate key.
> >
> > Ah, but in an XML document, this relation is "described" with the
> > "nodes". Do I get it now?
>
> No, I did not mean nodes there. I was talking about the order. It is
> just there.

Right.

> > It couldn't store anything you like :-) That's what was wrong.
>
> So can't the relational model too. Not anything, at least not in a
> natural way.

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

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server
Upscene Productions
http://www.upscene.com