[
Lists Home |
Date Index |
Thread Index
]
Michael Kay <michael.h.kay@ntlworld.com>
> > > 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.
Ok, I think I see where you're coming from. I guess I see the extra
relational semantics as being via auxiliary type tables. Not codified
in the relational model, but a pretty natural result of any (extensive?)
normalization?
> 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.
Yes, I've encountered this. It seems to have biased me into a philosophy
of avoiding a codification of my XML schema as much as possible; drive
the metadata out of the database and produce the schema on demand, after
the fact...
> 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.
My approach is to do ER modeling and OO modeling before I attack my XML
modeling. That was sort of the rational behind my original
question/thesis; I have a vague sort of technique for using ER modeling
for XML floating around somewhere in the back of my head (I currently
use mostly OO techniques for XML modeling). However, before going there
I should observe that doing relationship modeling correctly (whatever
correctly may mean) really is _the_ fundamental issue. I'm currently
coming down on the MDA side with a model early and model often
philosophy.
|
