Re: XML databases

From: dawn <dawnwolthuis_at_gmail.com>
Date: 8 May 2006 09:51:35 -0700
Message-ID: <1147107095.716686.70970_at_j33g2000cwa.googlegroups.com>


JOG wrote:
> This is essentially a request for help - I am (relatively urgently)
> searching out references that discuss XML databases with the view that
> they may in some cases be deleterious for information storage.
>
> I am looking for research work that indicates that, while XML can
> obviously handle irregular data, the artificial hierarchical
> constraints it introduces can produce undesirable query bias and hides
> many of the information's internal relationships.

I would think most of the same arguments against MV would hold for XML data stores. If one makes use of the nested lists within XML (which would be typical of an XML schema), then you have "arbitrarily" (or, perhaps, with good sound analysis) decided to model a hat size as a property of a person rather than seeing all data as equal ;-)

> I'm not intending to start a debate on XML - that's being had in many
> other threads - just looking for formal citeable references.

Everything that Codd or Date wrote prior to the 90's that includes any discussion of normalization and anything in the industry in support of what-was-once-termed-1NF would do, along with anything in support of a 3VL. It is wrong IMO, of course, but it would back up a position of query bias, for example.

> Anyhow
> anything of that nature, indicating potential deficiences (or benfits
> in fact) in the XML 'data model'.

If you would really like benefits, you have 2VL, NF2, and all (non-binary, non-mime/dime) types being subtypes of strings (which gets you some interesting benefits with similarities between handling and these documents, e.g. related rules, as handling user input, for example). The XML vs RM argument is very similar to the MV vs RM argument, with additions of a) more nested levels in XML, so it is more like Cache' MUMPS than Cache' PICK b) a distinction between attributes and entities in XML (that I don't find particularly helpful) and c) XML schema that may be used for enforcement or not, as desired.

My reason for bringing up the MV data model at all in this forum is related to the future, not the past. The fact that there are highly successful systems employed by highly successful companies that use something similar to an XML data model already, is evidence that at least it can be successful. I will grant that there are pros and cons to the use of a di-graph model with trees on the nodes, but any blanket dismissal of persisted XML due to the data model is likely based more on data model religion than experience.

> Anything you can share is much appreciated, Jim.

I did not intend for this to be an MV discussion and do not want to make it that, but in case you were not aware of the similarlies, I thought I'd pipe up before I head out. Cheers! --dawn Received on Mon May 08 2006 - 18:51:35 CEST

Original text of this message