[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Designing XML to Support Information Evolution

• To: "Chiusano Joseph" <chiusano_joseph@b...>
• Subject: RE: Designing XML to Support Information Evolution
• From: "Hunsberger, Peter" <Peter.Hunsberger@S...>
• Date: Mon, 17 May 2004 14:45:58 -0500
• Cc: "Roger L. Costello" <costello@m...>, <xml-dev@l...>
• Thread-index: AcQ8Pb4KjzXwsLXRTSediivWU6BBJwACM4Wg
• Thread-topic: Designing XML to Support Information Evolution

Chiusano Joseph <chiusano_joseph@b...> writes:

<snip/>

> > >
> > > 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.
> 
> The biggest issue right out of the gate, of course, is file 
> size - with XML files already being larger in size than 
> data-only files, this approach would take up inordinate 
> amounts of file size and bandwidth to transmit. That's a 
> complete show-stopper in many instances.

Ok, I see where you're going...  XML normalization can be a lot harder
than DB normalization, but yes, you need to be sensible.  That's why in
our case we separate the hierarchical metadata model from the actual
data.  The model is small, the data is large, but flat.  The exception,
is our data relationship model which is sort of half way in between:
it's only the data relationships and not all the data, but it can be a
big hierarchy.  

As long as you're using conventional computer systems you can't avoid
this, sooner or later you have to make the space time complexity trade
offs.  So, if you've got lots of time, go ahead build the hierarchy from
scratch, but be aware that a pre-assembled hierarchy can cut a couple of
orders of magnitude out of the processing time...

• Follow-Ups:
  • Re: Designing XML to Support Information Evolution
    • From: "Chiusano Joseph" <chiusano_joseph@b...>

• Prev by Date: Register for TechDoc Summer Workshops Today.... June 28-30 Crystal City, VA
• Next by Date: Re: Designing XML to Support Information Evolution
• Previous by thread: Re: Designing XML to Support Information Evolution
• Next by thread: Re: Designing XML to Support Information Evolution
• Index(es):
  • Date
  • Thread