[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xml-dev] Caught napping!
> -----Original Message-----
> From: Linda Grimaldi [mailto:firstname.lastname@example.org]
> Sent: Wednesday, November 07, 2001 11:26 AM
> To: email@example.com
> 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
> 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.