RE: storing xml files into database

[Frank Richards <frichards@softquad.com>]

Ilya,

I used to be an SE for a competitor of Excelon, so I'll jump in:

XML is a tree of elements. Naively mapping that tree onto a table causes the
RDBMS to
thrash it's guts out doing joins to go down the tree -- not to mention that
different content models
for different elements are painful too. The rule of thumb we passed out at
Poet was that the OODBMS
became faster than the RDBMS at three to four joins per query. XML in an
RDBMS can easily hit six or seven joins per query.

So, there are two normal ways around this:

1. Map your RDBMS schema on to your XML schema. This is where you get
scr*wed if you have changing schema, multiple schema or schema you don't
control. You have to change your DB schema every time your xml structure
changes. And getting a relational DBA to change a schema is like getting
Steve Ballmer to run OS/2, if not Linux.

2. Store whole xml docs as blobs. Now they're opaque, so suddenly you're
extracting information from them to store in relational tables so you can
actually use it. Which puts you right back in case 1, except you have data
integrity problems as well because of storing the info in the blob as well
as the table.

Frank

-----Original Message-----
From: Sterin, Ilya [mailto:Isterin@ciber.com]
Sent: Monday, September 10, 2001 10:07 AM
To: 'Chris Parkerson '; 'gharesh@vsnl.com '; ''Chuck White' '
Cc: ''Xml-Dev' '
Subject: RE: storing xml files into database


> Haresh:
> Since I work for a native XML database company, you might not
> consider my advice to be valid... but I'm going to give it anyways ;->
> I have customer story after customer story where the first
> thing they tried was Oracle or DB2 or SQL Server for storing
> their XML. It was a natural thing for them to try as they
> already had those products installed. They came to eXcelon
> primarily because they failed at making an RDBMS handle XML
> in a way that was useful. One of our customers, for example,
> had Oracle consultants create a benchmark on Oracle 9i
> against our consultants using eXcelon. Oracle was unable to
> complete the benchmark and we won the deal... and these were
> top-notch Oracle consultants.
> A couple of questions that will quickly let you know that an
> RDBMS is not going to work:
> 1) Are you dealing with XML data whose schema is not
> necessarily consistent from document to document or the
> schemas change often? The key advantage of using XML as a
> data model is extensibility: you lose that advantage when you
> store it in an RDBMS.

How do you loose the advantage.  No really, I am not trying to be sarcastic,
but you sound like a good
sales person without actually explaining the anwer.  Really, I'd like to
know.

> 2) Do you need to update this data often? All current RDBMS
> implementations (except for a beta utility available for
> Microsoft for SQL Server) do not allow incremental document
> updates. You must replace entire documents when you need to
> make a change as all of the RDBMS systems store the data as
> BLOBs. Most of our competitors in the XML DB world also do
> not allow incremental updates. This is very important should
> data need to change fairly often.

When do you not have to read through the whole document to change anything,
weather it's XML of flat data file.  Again, some technical expetise would
definitelly help this case.  Again, I am not doubting you, but rather am
very interested in this approach of not reading in a document to make a
change.  Yes, externally it might not seem that way, but internally?

> 3) Is performance and scalability important to you? We've
> tried both Oracle and DB2 with over 100,000 documents, which
> is a relatively small amount. Oracle fails the benchmark, and

Why does Oracle fail?  At what point does it choke?

Ilya

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.xml.org/ob/adm.pl>