> > Not entirely. It doesn't tell you anything about physical storage,
> > it does tell you about what should be stored (namely: "true"
> > values).
>
> ...from the point of view of the relational model. Do you want to
> claim that the true values in relational model are the only true
> values that can exist?

No, I claim that you store only true values - assertions, if you like.
There's no point for "NULL" either - if you want to go the purist
route.

I'm also not saying that the currentl SQL DBMSes are fully relational,
from what I've read, they are not.

> > I'm not saying OODBMSes won't work, just like XML-DBMSes might
> > work [in the future]. Nevertheless, there's no solid basis to store
> > objects unless you map them.
>
> Nobody claims that XML DBMS is the way to store your relational data.
> They are not.

Oh good ;-0

> But XML DBMS works better for storing semistructured
> documents that are accessed as single entities, that do not share any
> information between them. There is no normalization, some data are
> redundant.

Bah, redundant data...

No normalization and redundant data make storing data more complex
and maintaining constraints costly. There's no reason why you should
do that. Unless you're data-mining etc.

> It just has its own use case and do not try to evaluate its
> applicability for the typical applications for the relational databases.

What does an XML database do, according to you?

Is "XML" a data type?

> > Just because XML has gone way beyond its original "specification"
> > does not mean is has a solid foundation for data storage. Remember,
> > it was designed for data-exchange. And yes, it comes in handy
> > sometimes, I use it myself for certain things as well.
>
> Again, it is not suited for the data storage as you understand the
> term "data".

Well, we agree on that then.

> > > Please do not tell me that OO data model does not have math and
> > > logic.
> >
> > Then show it. What exactly defines the "oo data model"?
>
> I will check my "library" for the oo data model where they define it
> the same way relational model is defined. Would it be enough for you?

Please do so.

> > Who said I was going to introduce a relation?
>
> And how you are going to store information about keywords for the MS
> Word attachments, image size for the images, digital signatures for
> the executables in one column?

Why in one column?

What I mean is that I can surely think of a logical view of how this
data can be stored without XML.

> > I would certainly split up the XML document. It has no basis to be
> > kept together. Heck, that's why there's different parts in the
> > document. It holds info about several entities.
>
> Nope, it holds info about one real-world entity. You cannot split XML
> document as you cannot split an 32-bit integer. You can specify a
> query SELECT * FROM myTable WHERE myCol BETWEEN 1 AND 64, but you do
> not access each bit separately. An XML document is atomic entity. Period.

This is where XML fails the relational "certificate". Each item in a column
should store 1 value. Not many, like XML.

In the case of a 32-bit integer, a column should store just that. So I take
it
you look upon XML as a datatype for a column. Then yes, you need all
sorts of weird operators and so on...

But why can't an XML document be taken apart?

> > > > 3) keyword extracter
> > >
> > > A custom component that is supposed to parse the attachment
> > > completely each time you want to access it? Are you really
> > > proposing that?
> >
> > No, on insert, extract keywords :-)
>
> So that's the job for the DBMS you say?
> In case of XML I say that
> information already comes into the database preprocessed. How? I do
> not care.
> > > It's not. When you take a book in your hands, you see a first
> > > author, then a second one, and so on. So it is relevant info.
> >
> > If this is relevant info -> store it.
>
> False. You do not explicitly store all available relationships in
> RDBMS, but some are implicitly there.

You don't?

> Same with XML - some information
> is implicitly there. You don't need to store it explicitly.
>
> > If the position in the XML document is relevant, you're actually
> > making representation (of the XML document) a factor in the meaning
> > of the data. This sounds silly to me. Then again, I might be
> > nitpicking, but still.
>
> That is not representation. That is a data model. If data model
> explicitly says that order is important, then it is important.

Funny. This is where things went wrong in the "old days" before the
relational model.

> > > And in XML some information does not require adding unnatural
> > > constructs.
> >
> > You're thinking representation, not storage.
>
> I'm thinking about the logical view of the data. About something that
> in relational model is said that logical view of relations are tables.

No, not tables: relations. Tables and views. Or other derived relations,
if you like.

This is what makes the application - by itself - independent of the data.
You can change stuff, create a new view and off you go. Or at least,
that's the idea ;-)

> > This is a scary document ... it talks about "parent" and
> > "referredby" - pointers, which the relational model was supposed to
> > replace because it caused so many problems. And yes, "next" and
> > "previous" have been reintroduced as well. I guess it doesn't get
> > any better than this.
>
> Relational model was supposed to replace that stuff because it did not
> work in many cases, but in some it was perfectly ok. If I need to
> compute the shortest path from point A to point B with Dijkstra
> algorithm, relational model does not help me a lot simply because my
> algorithm is desined on a graph, not on relations. Why do you fail to
> see that not everything can be done in relational model?

If I want to count from 1 to 10, how does XML help me?

There's a difference between a program and data-storage. The
relational model is designed for data-storage. And a good one at that.
There is no substitute, there's no better.

> > Good for stylesheets :-)
>
> What does DTD or XSD have to do with stylesheets?

A silly remark from my side...

I seem to remember from the fist rise of XML that you could use
DTDs to validate an XML document. Stylesheets have nothing
to do with it, my mistake.

Don't take me wrong -- I find XML useful for all sorts of things.

But not for persistent largish data storage systems.

With regards,

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