Re: Designing XML to Support Information Evolution
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format