> > OO is no basis for storage, is it?
>
> Who speaks about the storage? Does relational model defines how data
> are stored?

Not entirely. It doesn't tell you anything about physical storage, it
does tell you about what should be stored (namely: "true" values).

> If I remember Codd correctly, he explicitly tells that
> relational model does not define how data are stored. That may be
> table, that may be some hash table or whatever you like.

Nevertheless, OO is a basis for programming.

> > OODBMS: yes, please, drop them :-)
>
> OODBMS does not tell how data are stored, but how they are accessed
> and manipulated. And I know at least one example of very successfull
> OODBMS use-case in the company where I worked before with a huge
> amount of geographical data (Europe and US, including the building
> polygons). Would RDBMS work there? Maybe... but not so good as OODBMS.
>
> > I'd rather see a decent OO <-> DBMS bridge.
>
> They are available, but most likely only in Java :)

Probably :-)

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.

> > Does XML introduce a data model? If so, please show me the basis
> > for this model.
>
> http://www.w3.org/XML/Datamodel.html

Are you serious?

"The data model for XML is very simple - or very abstract, depending on
one's point of view. XML provides no more than a baseline on which more
complex models can be built."

Huh? Now, where's the model :-)

> I'm almost sure that you find somewhere definition of the
> "XML-algebra", but also consider that it will be very similar to the
> one used in OODBMS. And there is formal model for OODBMS.

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.

> > The relational model has math and logic as its basis.
>
> 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"?

> > One of the primary reasons to create the relational model is
> > data independence. How can the above not be done in a
> > (R)DBMS? I don't see the benefit of XML here.
>
> You just understand data in XML wrong.

Perhaps - part of the reason why I'm sending this e-mails :-)

> Data in the XML I mentioned
> before is not a first name or last name or a chapter title, but the
> complete document. Not more and not less. So
>
> > 1) user defined types (eg: domains)
>
> Ugu, and how you're going to introduce a relation as a domain keeping
> the database at least in first normal form? :)

Who said I was going to introduce a relation?

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.

> > 2) being able to create the basic operators on the domains
>
> Wait, aren't you already beyond the relational model?

No, not quite. A "domain" is more than a subtype of existing (= implemented)
datatypes and a simple check constraint.

The major products don't implement it as such though.

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

> > A position field? Why? If one author is more important than another,
> > then yes, there better be a position field. Cause if the position is
> > based upon the "position" in the XML document, then it's really
> > plain silly.
>
> 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.

> But in
> relational model you have to add that field explicitly, because
> relational model explicitly states that there is no order between tuples.

Yes, of course. If this is relevant, it should be stored.

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.

> > You should store data, if position is part of the data, store it. If
> > the representation of your data inside an XML document containts
> > info about the data, you're doing things the wrong way.
>
> That's your private opinion caused by your "relational" thinking. I do
> not care about storing information. I want to have the information.
> And in XML some information does not require adding unnatural constructs.

You're thinking representation, not storage.

> > Then, I ask you: what is the solid basis for the model. How is it
> > even a model?
>
> http://elib.cs.berkeley.edu/seminar/2000/20000207.pdf
>
> Your problem is that you do not consider graph and operations on graph
> to have solid mathematical background.

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.

> > but constraints are part of the basis of the relational model and
> > a decent (R)DBMS. It's the best we can do to ensure that our DBMS
> > knows what the data means and enforces integrity. How does this work
> > with XML?
>
> You have a DTD and an XSD. The document that conforms the DTD or XSD
> is considered consistent. If a transformation applied to the XML
> document does not satisfy the target DTD/XSD it is considered
> inconsistent.

Good for stylesheets :-)

With regards,

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