[
Lists Home |
Date Index |
Thread Index
]
> > Probably the greatest weakness of XML as a data model for
> databases is that it
> > doesn't provide a coherent way of modelling the non-hierarchical
> relationships.
> > But that's a weakness of the relational model too.
>
> I'm having a hard time parsing this. Did you perhaps mean
> the inverse;
> that the relational model has a hard time modeling hierarchical
> relationships? Or is this a general comment about the difficulties in
> modeling for the relational model? If it's the latter I'd disagree;
> just about anyone can at least do a first normal form model. That may
> not get you real far, but tools abound as do training, books
> and tons of
> best practices to fall back on.
Well, the relational model has a consistent story on how relationships are
modelled, using primary keys and foreign keys. It's not a very
semantically-rich model, but it's clean and consistent.
XML has a clear story on hierarchical relationships, but a very confused
story on those that aren't hierarchical. There are lots of ways of doing it:
URIs, IDREFs, XLinks, or just "unmarked" foreign keys. None of these is
clearly definitive. Moreover, XML forces you to treat one particular
relationship (the parent-child relationship) very differently from all the
other relationships, so you have to make an early design decision that won't
necessarily be convenient for everyone for all time.
There are probably two design decisions in XML that are really hard to make
correctly, yet very hard to change later. One is "what goes in a document?",
the other is "which relationships should be represented as parent-child
relationships?". One could add a third, elements versus attributes, but
that's fairly trivial in comparison. Sometimes one can make these decisions
instinctively, but I've come across many cases where the answers are far
from obvious, and there's no discipline akin to relational normalization
that gives you the answer.
Michael Kay
|
