[
Lists Home |
Date Index |
Thread Index
]
Chiusano Joseph <chiusano_joseph@bah.com> writes:
>
> "Hunsberger, Peter" wrote:
> >
> > Roger L. Costello <costello@mitre.org> writes:
> >
> > <snip>example</snip>
> >
> > > Here are some lessons I learned. I believe these lessons
> apply to
> > > all
> > XML information structures where you have a requirement to
> > > evolve the information structure by moving the information (e.g.,
> > > move
> > the Picker around to different lots), changing the
> > > information values (e.g., a Pickers harvests ripe grapes, thereby
> > decreasing the value of <ripe-grapes> on a lot), and where
> > > parallel processing of the information is desired/needed. I don't
> > know if these lessons apply everywhere.
> > >
> > > 1. How you structure your information in XML has a
> tremendous impact
> > on the processing of the information.
> > >
> > >
> > >
> > >
> > > 2. Hierarchy makes processing information hard! There exists a
> > relationship between hierarchy of information and the
> > > complexity of code to process the information. The
> relationship is
> > roughly: the greater the hierarchy, the greater the
> > > complexity of code to process the information (Some hierarchy is
> > good, of course. But the amount of hierarchy that is
> > > good is probably much less than one might imagine, certainly less
> > > than
> > I thought, as described above.)
> >
> > Hierarchy makes processing non-hierarchical data hard. As
> others have
> > suggested, it would seem that you created a hierarchy where
> none was
> > needed. You can always normalize a hierarchy in a database (eg.
> > set/subset relational models for example), but when trying
> to reflect
> > a hierarchy for presentation purposes a hierarchy is the
> best way to
> > represent hierarchical data... Gluing back together parent child
> > relationships can also be inefficient!
>
> Of course, in some cases this can violate second and/or third
> normal form (I forget which - it might be both...it's been a
> long time since I studied this in my undergrad, and it's now
> become instinct;). Using Roger's original example, let's say
> that we have a business rule that allows a picker to belong
> to multiple lots - perhaps we're short on pickers and need to
> share them among multiple lots in alternating shifts. Let's
> also say that we need to represent properties of a picker
> - I'm a city boy so I'll take my best guess...manufacturer,
> size, etc. Repeating the properties of a picker over and over
> for each lot to which it is assigned violates one or both of
> those normal forms.
>
Umm, yes, but I'm not sure what the issue is? Store the data
relationally, fully normalized, represent it hierarchically.
I'm currently experimenting with having one master data relationship
table that holds all our hierarchical data relationships in fifth normal
form (mostly, but the one possible violation so far hasn't been needed
-- that's another story). By the time any portion of it makes it to the
front end it has up to 11 levels of hierarchy that can in turn have
many-to-many relationships with other portions of the data. Query
performance is amazing, insert speed might be an issue in one particular
case, but it's rare.
The key thing here is; on the XML side, hierarchy can be good. On the
DB side; do what comes naturally to the DB you're using...
<snip/>
|
