Re: Data storage, data exchange, data manipulation

[Ronald Bourret <rpbourret@rpbourret.com>]

Jeff Lowery wrote:
> I think object-relational databases have some promise. Knowing how to
> decompose and XML hierarchy just enough to result in an efficient relation
> model is more of an art than a science right now: I don't think you get much
> benefit if all parent-child relations are rigorously broken down into
> primary/FK pairs, for instance.

I think this is very true and will probably remain an art. One
experience we've gotten from tools that automatically generate database
schema from DTDs is that it often results in very inefficient storage
models. The reason is that XML encourages (often with good reason)
wrapper elements such as Address in the following:

   <Customer>
      <Name>O-R Industries</Name>
      <Address>
         <Street>123 Big Iron Dr.</Street>
         <City>Anywheresville</City>
         <PostCode>1234</PostCode>
      </Address>
   </Customer>

When you store this in the database, you probably want to store the
address in the customers table, not a separate table. However, the
Address element allows you to do some generic processing in the
application -- for example, you could hand off the <Address> element to
a routine that built an Address object.

This basically amounts to a way to do explicit data typing in the XML
document (as opposed to the schema). In the case of the address element,
you're defining a complex data type. I've even seen it used for scalar
data types, such as:

   <Price><Money>1.23</Money></Price>

or

   <Attendance><PositiveInteger>35</PositiveInteger></Attendance>

-- Ron