> > > In terms of relational data model you can think so.
> >
> > In that case, it doesn't fit into the relational model at all as it
> > doesn't store "one value".
>
> Then same applies to BLOB - it does not fit relational model too. I
> think you're wrong here.

If the blob holds a single value (eg: "movie"), why is it wrong?

> > There's nothing wrong with thousands of tables.
>
> What about supporting them?

There are plenty of systems with hundreds or thousands of
tables. If this is what it takes to guarantee data consistency,
fine with me.

> > > Because if you split your XML document apart it is no longer XML
> > > document that satisfies your DTD/XSD. It is something completely
> > > different, similar to extracting bits from your integer.
> >
> > Instead, you have your relational constraints to validate it. As
> > long as you can recreate your XML document, what's wrong with it?
>
> First, you have an answer in the original article - you loose
> performance. Second, you try to access single "bits" of the atomic
> entity with your queries. That is not natural, though perfectly legal.

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

Sounds messy.

> > Yes, it perhaps might be _easier_ to store it as an XML document,
> > but does that justify the current hype?
>
> Sure. If people need to store and query XML documents, a native XML
> store is the solution.

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

> > > No, some you build with joins.
> >
> > I disagree here. There's no point in joining unrelated data.
>
> 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?

> > Well yes, but we can store the data from the complex structure
> > without the need for the complex structure.
>
> Sure, but you always want to compose/decompose that complex structure
> into parts that from your point of view are atomic, execute query on
> that parts and then assemble them again back into molecule. They
> propose to treat molecule as an atom and define new query language
> optimized to querying molecules.
>
> > Performance has nothing to do with the relational model. Performance
> > is implementation defined. The relation model is a logical model.
>
> It has. What's wrong with hierarchical model, unless you consider how
> many CPU cycles were burnt in order to extract some simple information?

It couldn't store anything you like :-) That's what was wrong.

> > There's no argueing that one implementation of a certain model
> > performs differently from another implementation.
> >
> > But to dismiss the relational model as a foundation for data storage
> > because current implementations perform like a fat dog doesn't hold
> > merit.
>
> I dismiss it in certain cases as the model that is not applicable for
> my information. You can try to describe a 1 m3 of our air with quantum
> model, but you will not succeed (or maybe you would if you were
> immortal and you were God). Though thermodynamical model describes it
> perfectly (and introduces some new properties like temperature, that
> in fact does not exist - there is no temperature of an atom, but you
> can easily tell that it is cold outside).

These are fully different levels of looking upon problems. Not every
logical view can be used for a specific problem.

> > Go complain with the vendors to make better products.
> >
> > There's no need to go the OODBMS route ;-)
>
> There is such need. :) Your claims are like claims of a person who
> just discovered quantum theory and general relativity theory and
> starts to claim that all other theories should be deprecated because
> one can always describe something using that two. Sorry, but that does
> not work in all cases. Maybe for God, but not for you. :)

If there's a solid basis for OO-based storage, fine. But there isn't
any. That is the problem.

With regards,

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