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

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] storing XML files]



Just wanted to add a little info regarding #3 below.  NeoCore's XML
Information Management Server does not have this problem.  Our native
XML database is based on Digital Pattern Processing.  It does not index
in a pure sense, but converts an XML document to an iconic
representation.  This "indexes" everything in the document and
eliminates the problem described in #3 below.  I think this is a good
example of the trend where native XML databases are becoming more robust
in their performance and warrant consideration for the types of
applications so well described earlier in this thread.

A free eval of NeoCore XMS is available at
http://www.neocore.com/evaluation/download.htm. 

Eric Lemond
NeoCore

>Ronald Bourett wrote:

>Furthermore, native XML databases are not guaranteed to outperform
>XML-enabled relational databases in all cases. As a general rule:

>1) Native XML databases should outperform XML-enabled relational
>databases on queries along the XML hierarchy, such as XPath queries.

>2) It's anybody's guess which will perform better on queries not along
>the hierarchy, such as a query that inverts an XML document.
>Theoretically, it seems that if the queried fields are indexed in both
>types of database and similarly clever people implement the query and
>storage engines, performance should be comparable. However, I don't
know
>enough about storage and query engines to know if this is true.

>3) Native XML databases could encounter serious problems querying
>unindexed data. This is because they have to search many more nodes to
>find the data. That is, first they have to determine if a node is the
>correct node ("Are you a foo element?"), then they have to look at the
>data for the node ("Is your value 'bar'?"). Relational databases only
>have to look at a given set of column values.