[
Lists Home |
Date Index |
Thread Index
]
> etc. (Possibly at this point you add in database constraints that didn't
> previously exist, turn certain fields non-null, etc.)
Sounds like you are using a relational database to store your XML. Talk
about an impedance mismatch. Why even bother with XML in the first place if
you are shredding it or clobbing it? (I know, because that is what the
design says, or that is what is delivered to you -- but does that mean you
have to live in the XML world? And if you are, then move up to better data
management technology than something invented 20 years before XML)
In order to realize the real-time XML document delivery as actionable item
[taken from previous post], you really need to have the XML in its native
form, and be able to not only query within a document, but between and
across documents as well. Being able to do inserts, updates and deletes
within and across documents with a single command (server side) without
round tripping the XML documents (to the client) is the only way this will
scale. I don't know any way to do this without a self-constructing XML
database.
I say self-constructing, because in real life situations, you don't
necessarily know the structure/values in an XML document (as has been
pointed out numerous times by many people in this forum) that you are
receiving, but may need to store it (and raise an exception) for later
processing.
This is traditionally the breakdown when constraints are violated (like
hiring a 14 year old when the rules says 16) in an RDBMS, because you cannot
simply store the "almost good" data due to field constraints, and although
you may have checked it against multiple schemas, I have never met a DBA who
wouldn't also implement the rule in the DB, "to make sure the data is always
correct".
"Data integrity" is an oxymoron.
Owen
http://www.xpriori.com/developers/html/downloads.html
|
