[
Lists Home |
Date Index |
Thread Index
]
--- Rick Marshall <rjm@zenucom.com> wrote:
> <customer>
> <name>COMPANY X</name>
> <town>SOMEWHERE</town>
> <order>
> <part>ABC123</part>
> <quantity>2</quantity>
> </order>
> <order>
> <part>ABC234</part>
> <quantity>4</quantity>
> </order>
> </customer>
>
> just isn't going to be a relational form as there's
> no way to determine
> a priori what the normalised records are....
> so without some semantics you can't represent
> relational tables with the
> natural tree structure of xml.
Yup. The hierarchical approach that XML supports
allows you to not worry about the sometimes
challenging problem of figuring out what the keys
would be in a normalization that will allow you to get
back the information you put in. It's sortof like the
fox and hedgehog: the relational model has a many
tricks for defining relationships among components,
but you have to be clever to use it well; XML has only
one trick ("containment") but it's a pretty powerful
one. Of course, not all data fit the "natural tree
structure of XML" but a lot of interesting examples
do.
The downside, which I think is the point of this
thread (I haven't read the whole thing!) is that XML's
"one big trick" works best if the document as a whole
is the unit of analysis and storage. Once you start
composing compound documents out of individual
entities or need to update specific
elements/attributes inside an entity, things start to
get very ugly and there's little in the way of a
theoretical model such as Codd developed to guide you.
For example, there is a more or less irresolveable
muddle between the XML syntax level model of entity
declarations and references and the
Infoset/XPath/XQuery model in which these are assumed
to have been resolved. (DOM tries to play on both
sides of the street, but that part of its conceptual
model is very ugly).
XQuery is probably a great breakthrough here by
allowing both the implicit containment relationships
that the relational model lacks and allowing documents
to be composed by a Join operation on shared values,
which AFAIK is the most profoundly powerful aspect of
the RM. Whether XQuery implementations can be written
in a way so as to make this practical for
terabyte-scale databases is yet to be seen ... but I
have to assume that (pulling numbers out of the air) a
3-way Join of hierarchical document collections will
be more practical than 100-way joins across normalized
relations containing the components of complex
documents such as aircraft maintenance manuals.
|
