Re: storing xml files into database

[Kimbro Staken <kstaken@dbxmlgroup.com>]

You can find a couple links to benchmarks here. 
http://www.xmldb.org/resources.html#benchmarks

Unfortunately they both chose to use XQuery which severely limits their 
applicability to current products.


Kimbro Staken
The dbXML Group L.L.C. - http://www.dbxmlgroup.com/
Embedded XML Database Software and Services

On Monday, September 10, 2001, at 11:00 AM, Chris Parkerson wrote:

> It would be nice if we could find an independent entity to benchmark us
> all... I think there are enough of us in the XML DB and XML-enabled DB
> market now to submit to an independent benchmark ;->  We've been
> building ours since 1997 ;->.
>
> We've spent a lot of our own resources on standalone and competitive
> benchmarking (well, against the products we can get a hold of... so far,
> we've only been able to do that with the RDBMS vendors... the rest of
> you XML DB vendors do not have fully-functional evals like we at eXcelon
> do ;->).
>
> If not ZapThink, maybe there's someone else on this list that can
> coordinate such an independent benchmark.
>
> Cheers,
> Chris
>
> ---------------------------------------
> Chris Parkerson
> Product Manager
> eXcelon Corporation
> Burlington, MA
> (781) 674-5393
> http://www.exceloncorp.com
> ---------------------------------------
>
>
> -----Original Message-----
> From: Bill Lindsey [mailto:bill@blnz.com]
> Sent: Monday, September 10, 2001 1:08 PM
> To: xml-dev@lists.xml.org
> Subject: Re: storing xml files into database
>
> Frank Richards wrote:
>> 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 --
> [ ... ]
>> XML in an
>> RDBMS can easily hit six or seven joins per query.
>
> A typical, naive definition of a "nodes" table does lead to unacceptable
>
> performance due to the necessity of many self-joins.  It is possible,
> however, to devise a scheme for encoding nodes' context in a compact
> form, optimized for an RDBMS' indexing facility, and build a
> generic table structure, capable of storing any well-formed
> XML, yet does not exhibit the self-join problem.
>
> With this technique, one can:
> * leverage the mature ACID properties of commercial RDBMSs
> * support any well formed XML with no additional developer or DBA effort
> * provide fine-grained, random access to the content of large
> collections
> * efficiently query on content and/or structure
>
> Bill Lindsey
> B-Bop
>
> -----------------------------------------------------------------
> 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>
>
>
> -----------------------------------------------------------------
> 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>
>