[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: Caught napping!
- From: Linda Grimaldi <firstname.lastname@example.org>
- Date: Wed, 07 Nov 2001 09:26:08 -0700
- Delivered-to: email@example.com
- Thread-index: AcFnqOfbbVgk3mTARRyq/eV/HDdbsw==
- Thread-topic: Caught napping!
I just picked up on the database decision tree thread. Life has been
hectic, but boy was I remiss. Hope it's not too late to throw my 2
cents in- you know I'm going to anyway...
I was generally really impressed by the discussion, but I think there
might be an aspect to it that is missing. It's a little more "Zen of
XML" oriented, but I think it is worth considering.
XML is a carrier of data plus context, data plus metadata. This is
obvious, but is often lost in document design. When I look at a lot of
schemas out there these days, they are often blatantly influenced by an
underlying relational mentality. This is not a bad thing if your
eventual target is an existing relational database. My question is
this: If the ersistence mechanism used were not relational, but if it
treated XML as XML in a very fundamental way- symmetrically handling
data and metadata, for example- would schema design change in any
fundamental ways, particularly for "new" data? We tend to put the
schema before the persistence choice. If we did it the other way
around, would anything change? 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.
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. (O/R mapping tools helped, but the solution was less than
satisfactory and a real pain to maintain.) The ability to persist and
manage XML "natively" may now give us the choice. The analogy with
OODBMS is not inappropriate, but XML has the advantage of being the
preferred transport mechanism as well, and old-style OODBMS still
Does this make any sense?