[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML versus Relational Database
----- Original Message ----- From: "Dylan Walsh" <Dylan.Walsh@K...> To: "Kimbro Staken" <kstaken@d...> Cc: <soumitra@b...>; <xml-dev@l...> Sent: Monday, February 05, 2001 3:01 AM Subject: RE: XML versus Relational Database > > -----Original Message----- > > From: Kimbro Staken [SMTP:kstaken@d...] > > Sent: Friday, February 02, 2001 5:44 PM > > To: Dylan Walsh > > Cc: soumitra@b...; xml-dev@l... > > 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|