[
Lists Home |
Date Index |
Thread Index
]
Roger L. Costello wrote:
> When I first started working on the demo I thought that the best way to
> design the XML for the Vineyard/Picker system was a "classical" highly
> structured, hierarchical design. In fact, this turned out to be the worst
> approach. It was rigid, it made processing the information (e.g., moving
> the Pickers around, harvesting ripe grapes, eating, death) horribly complex,
> and I wanted to be able to process the Vineyard lots in a parallel fashion,
> which this design totally prohibited. Here was my first design:
> ...
> Here are some lessons I learned...
Kian-Tat and Mike already pointed out that you are rediscovering some of
the strengths of the relational model. But there is more to be said, I
think.
This is an exercise in data modeling. It is possible to do a good part
of your data model without comitting to relational, object,
entity-relational, hierarchical, or what have you. You need to let the
data model and what you need to do with it guide its design.
For example, adding the hierarchical information that you did adds
information - strict, ordered data - to the data model. The only reason
you would want to do that would be if you needed it for some reason, but
apparently you didn't. So right off the bat, you made you job much
harder, and the root cause is that you did not work out the data model
sufficiently.
For another example, in the world of relational databases, there are
dependent and independent tables. The rows of a dependent table cannot
exist without some other table (the primary keys(s) of the dependant
table are foreign keys into the other one). The data modeling question
here is whether the pickers are dependent or independent entities.
Since they can be moved from lot to lot, clearly they are not dependent
on lots or tracts. Thus they are independent entities, and they had no
business being modeled into the tracts and lots.
This conclusion has nothing to do with using hierarchies or not, or even
xml vs relational. The pickers are simply independent entities. You
could have linked them to the lots or tracts by using an xlink linkbase,
instead of reinventing link methods as you did (not that there is
anything wrong with doing it the way you ended up with).
So far as the tracts and lots go, you have not told us enough to assess
whether the lots should be considered as contained by the tracts. Here,
the issue is whether you want to do anything with that information or
not. It seems as if you just need to look up the tract data for a given
lot. In that case, the fact that the lots are contained in the tracts
may be irrelevant, and thus should not have been modeled - since it adds
complexity for no returned value, as you discovered.
So with a little more work on the data model, you could have gotten
directly to your final result, or something much like it. If the
purpose of the exercise (or other parts of the data model that we have
not seen) had been different, you might have done better to put the lots
into the tracts, but apparently not in this case.
So the lesson I am obviously pushing here is that good data modeling is
as important as it ever was, xml or no.
Cheers,
Tom P
|
