Re: XML versus Relational Database

[Kimbro Staken <kstaken@dbxmlgroup.com>]

----- Original Message -----
From: "Dylan Walsh" <Dylan.Walsh@Kadius.com>
To: "Kimbro Staken" <kstaken@dbxmlgroup.com>
Cc: <soumitra@b-bop.com>; <xml-dev@lists.xml.org>
Sent: Monday, February 05, 2001 3:01 AM
Subject: RE: XML versus Relational Database


> > -----Original Message-----
> > From: Kimbro Staken [SMTP:kstaken@dbxmlgroup.com]
> > Sent: Friday, February 02, 2001 5:44 PM
> > To: Dylan Walsh
> > Cc: soumitra@b-bop.com; xml-dev@lists.xml.org
> > Subject: Re: XML versus Relational Database
> >
> >Storing XML in a file or in a text blob in a RDBMS works fine as long as
> >you always treat the XML as one atomic unit and can handle the hit of
> >parsing the document each time it is retrieved from storage. If your XML
> >is static this works fine but if the application is changing the XML
> >then a more robust mechanism might be in order.
>
> Might their not be a greater hit in assembling all the DOM nodes, coming
> back in pieces, compared to reading the whole XML document in one database
> operation and parsing it in your application? There has got to be an
> overhead in reading/writing possibly thousands of items of data, using
many
> queries, instead of a single read/write of a text blob.

If you're assuming a mapping to an underlying relational database then
you're right, the hit will probably be greater. However, I didn't really
have relational mapping in mind when writing that comment. I'm currently
working on a native XML database so my perspective is skewed in that
direction.

What is funny though is that my realization that something more then an
RDBMS was needed came about after I completed a project using a relational
database exactly as you describe. We stored XML data as text blobs in the
database and this worked fine for basic read and write operations with a
single thread updating the same document at the same time. It also worked
fine as long as using an ID was sufficient for retrieving the XML. For us
this worked well for our primary application but ran into problems when we
started doing management of the data stored within the blobs. For instance
there was no easy way to update a particular element in all documents in the
database, there was no easy way to query and find a set of documents that
matched a particular pattern and therefore there was no easy way to generate
reports on what was in the data or how the application was being used. This
list goes on well beyond this but this should be sufficient to generally see
why for simple cases what you are saying will work but it doesn't work very
well as you get more in depth. At the time I built that application there
was no alternative for XML storage, now there are choices and development is
very active to solve this problem. Which solution is the best of course
still depends largely on your particular requirements. I find the native
approach to be very appealing but there are also other options that you
might want to explore rather then just storing blobs of text in a RDBMS.
Just my 2 pennies of course. :-)

>
> Last summer I asked a question about how best to store XML in an RDBMS.
One
> response likened the decomposition approach to taking your car apart every
> night when you park it, and rebuilding it in the morning.

Yes this is very true and is another one of the reasons that you now see the
development of native XML databases.

>
>

Kimbro Staken
Chief Technology Officer
The dbXML Group L.L.C.
http://www.dbxmlgroup.com