OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Storage of XML documents & Learning from history

[ Lists Home | Date Index | Thread Index ]
  • From: "Michael Champion" <Mike.Champion@softwareag-usa.com>
  • To: "Michael Rys" <mrys@microsoft.com>, "'Kay Michael'" <Michael.Kay@icl.com>, "'Dylan Walsh'" <Dylan.Walsh@Kadius.com>, <xml-dev@xml.org>
  • Date: Fri, 12 May 2000 14:48:59 -0400


----- Original Message -----
From: "Michael Rys" <mrys@microsoft.com>
To: "'Kay Michael'" <Michael.Kay@icl.com>; "'Dylan Walsh'"
<Dylan.Walsh@Kadius.com>; <xml-dev@xml.org>
Sent: Friday, May 12, 2000 1:37 PM
Subject: RE: Storage of XML documents & Learning from history



> > If you do need fine-grained storage, use an object database; relational
> > storage of these structures will in general be grotesque.
>
> Here I disagree.
[snip]
>  relational storage
> may be as adequate.
>
> Shameless plug:
> For a tool in a relational context to do both look at the OpenXML XML
rowset
> provider in SQLServer 2000

Well, since we're shamelessly plugging our own technologies ;~) I'd like to
point out that a native XML database such as www.softwareag.com/tamino
allows fine-grained storage without the tradeoffs mentioned in this thread.
Since the XML maps directly onto hierarchical database structures, there's
minimal decomposition/reassembly cost as their would be in normalizing the
data into pure RDBMS structures.  As I understand it, the performance
advantages that are often observed for OODBMS (and hierarchical databases
such as IMS and Adabas) in non-XML applications come from their ability to
easily represent real-world data models without the need for decomposition
on storage and JOINs on retrieval. The same pattern will surely hold for XML
data.

Likewise, with a native XML DB there's no loss of queryability (or need to
define and extract queryable "metadata") as there would be in a BLOB or
combined fine grain/coarse grain strategy.  In evolving real-world
applications, the "few pieces of information needed to do queries" may be
difficult to define in advance, or may change as the application matures.
In a native XML DB, all elements and attributes can be queryable without an
excessive storage or processing overhead.

Finally, a native XML database built on the underpinnings of a proven
hierarchical database engine is likely to show more scalability,
reliability, integrity over complex transactions, etc. than an OODBMS.


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS