OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [xml-dev] Caught napping!





> -----Original Message-----
> From: Linda Grimaldi [mailto:lgrimaldi@neocore.com]
> Sent: Wednesday, November 07, 2001 11:26 AM
> To: xml-dev@lists.xml.org
> Subject: [xml-dev] Caught napping!
> 

> Referential integrity, for example,
> between such mundane objects as customers and purchase orders might be
> accomodated by treating the customer and his list of POs as a single
> doc.  Or, if the implementation is efficient enough in terms of data
> footprint, by replicating customer data on each PO.

Right.  I think I wrote of my quasi-revelation a few years ago when thinking
about how to present "bookstore" data normalized into 20-some tables on a
website.  Since the bookstore is not going to change the redundant
information anyway, an XML database representation of an entire hierarchical
catalog entry can be more attractive than a 20-way join, or a kludgy
denormalization.  


> We tend to shape our data to fit our container, not the other way
> around. In general, this was because we had no choice. Many a 
> wonderful object model has gone astray when tossed upon the shoals of 
> RDBMS design constraints.  

> 
> Does this make any sense?

Definitely!  Even more so in light of the SAX/DOM thread ...  It's the old
saw (sometimes given academic respectability as The Law of the Instrument):
"to a small child with a hammer, everything looks like a nail."  We need  a
toolbox full of data models, storage models, APIs, etc. and the knowledge of
when one or the other best suits a particular job. SAX and DOM and JAXB and
whatever, and XML DBs and RDBMS and OODBMS all probably have their
appropriate uses, and we need to do a better job of understanding and
comunicating what those optimal uses actually are.