[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Database Decision Tree?

  • From: Jeff Greif <jgreif@a...>
  • To: "Champion, Mike" <Mike.Champion@S...>, xml-dev@l...
  • Date: Wed, 17 Oct 2001 17:15:20 -0700

xml referential integrity
Some forms of intra-document referential integrity could be in the form of
idrefs required to match ids.  Perhaps xlink could be used to provide some
inter-document referential integrity, and I suppose some fragment - fragment
referential integrity within a document.  I wonder if the Schematron engine
could be adapted to check other kinds of constraints, even between
documents.

Clearly people can implement contracts management in RDBMS, storing the
(digitally signed) text as a CLOB, and shredding into elements suitable for
relational storage.  If the customer address has to be preserved against
changes for the sake of the contract, then you would store addresses in an
address-history table.  (And all those elementary SQL examples where you
give everyone a 10% raise should not update a salary in the employee record,
but insert in a salary-history table.)

Jeff
----- Original Message -----
From: "Champion, Mike" <Mike.Champion@S...>
To: <xml-dev@l...>
Sent: Wednesday, October 17, 2001 11:34 AM
Subject: RE:  XML Database Decision Tree?


...
> My point is XML *itself* has no conception of referential integrity; the
> problem doesn't go away by storing it in an XML-enabled RDBMS of some
sort.
> Disagree?
>
> Solving the problem via RDBMS technology would seem to require documenting
> the mapping of XML onto the internal RDBMS representation in a way that
XML
> users could exploit, e.g., to cause entity references to be re-expanded
> after the content of an external entity changes.  That's the kind of thing
> that RDBMS triggers do, and I can imagine how an XML DBMS built on RDBMS
> technology could exploit it ... but it's not obvious to me. Furthermore,
> this could require the end-user to understand the internal storage
> architecture, and data independence (to steal an RDBMS term) is the whole
> *point* of a native XML DBMS, as I see it.  And once you start talking
about
> triggers, this is not part of the relational model, just implementation
> technology that "proprietary database technology" could do just as easily
as
> an RDBMS.  What am I missing here?
>
...
> If you WANT your XML representation to change when an underlying
information
> item changes (e.g., the customer address in a purchase order should change
> when the address in the customer database changes), RDBMS-based solutions
of
> one sort or another are generally more appropriate.  If you want the XML
> representation to reflect a snapshot of reality (e.g., the XML purchase
> order is a "contract" that is digitally signed for purposes of
> non-repudiation), and you don't want the XML representation to change
> (breaking the digital signature!) when the underlying data changes, a
native
> XML DBMS are generally more appropriate.
>



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.