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

Sure, the first normal form is one of the examples.

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

Again, I'm storing a document. The document is atomic entity that is
stored. There is no redundant data there as there is no redundancy in
bits that make an integer.

> What does an XML database do, according to you?

Stores XML documents and allows to execute queries on the XML
documents. Think of it as one big table with one big column and
completely different query language.

> Is "XML" a data type?

In terms of relational data model you can think so.

> Please do so.

Ok, later today.

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

Will you for each new "addition" in a record extend your data schema?
You will end up with thousands of tables.

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

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.

> > False. You do not explicitly store all available relationships in
> > RDBMS, but some are implicitly there.
>
> You don't?

No, some you build with joins.

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

They were not wrong, they simply did not fit all cases.

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

If I'm not wrong, Codd talks about logical representation as tables
with columns.

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

Same there. Just your view consists of one column and each row there
is a complex structure with its own access methods.

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

Wrong. Relational model is bad on performance in CAD/GIS applications.
That's why OODBMS happened. There is no silver bullet.

> But not for persistent largish data storage systems.

Depends on the data and your tasks. As I said before, I know at least
one example where OODBMS performs very good, much better than
relational database would. And this is because objects are linked
together with pointers and no query is needed when I navigate from one
object to another.

Roman