[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Designing XML to Support Information Evolution
Chiusano Joseph <chiusano_joseph@b...> writes: > > "Hunsberger, Peter" wrote: > > > > Roger L. Costello <costello@m...> 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/>
|
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
|