Cart
[Home] [By Thread] [By Date] [Recent Entries]
> -----Original Message----- > From: Linda Grimaldi [mailto:lgrimaldi@n...] > Sent: Wednesday, November 07, 2001 11:26 AM > To: xml-dev@l... > Subject: 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.
|
