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

In that case, it doesn't fit into the relational model at all as it doesn't
store "one value".

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

There's nothing wrong 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.

Instead, you have your relational constraints to validate it. As long
as you can recreate your XML document, what's wrong with it?

Yes, it perhaps might be _easier_ to store it as an XML document,
but does that justify the current hype?

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

I disagree here. There's no point in joining unrelated data.

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

As far as I know, it's always "relations", but we can quit on this one.

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

Well yes, but we can store the data from the complex structure without
the need for the complex structure.

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

Performance has nothing to do with the relational model. Performance
is implementation defined. The relation model is a logical model.

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

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.

Go complain with the vendors to make better products.

There's no need to go the OODBMS route ;-)

With regards,

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