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: storing xml files into database



Haresh:
If you have needs for the highest performance, let me suggest NeoCore's
XML Management System (XMS).  However, I think it may be more horsepower
than you need for your application, so here's an open source xml db
initiative (http://exist.sourceforge.net/).  I don't much about it, but
it might be worth a look.

Ilya:
I can't speak to the XIS product, but I can speak to some of these
questions in terms of the NeoCore XML Management System (XMS).  

>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.

I can give an example of the benefits of extensibility.  One of our
clients wants to open inventory information to their customers.  With an
XML database or an RDBMS, the application can be set up for the first
customer.  Customer #2 wants to use the application too, but needs
additional fields and information.  With an RDBMS it is not easy to add
these fields after the fact.  With an XML database like NeoCore's XMS it
is very simple because it unleashes the extensibility inherent in XML.
This is the big advantage.  

>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?

NeoCore's XMS uses our patented technology called Digital Pattern
Processing (DPP).  We have a technical whitepaper that explains this
technology at http://www.neocore.com/products/products.htm.  Basically,
DPP uses algorithms developed over about 10 years to change an XML
document into what we call an icon representation.  This makes searching
and incremental updates with XMS faster than anything we have been able
to test it against.  

Ilya, I hope that I've been able to shed a little more light on XML
databases in the context of NeoCore's unique solution.

Best,
Eric Lemond
Analyst
NeoCore
-----Original Message-----
From: Sterin, Ilya [mailto:Isterin@ciber.com] 
Sent: Monday, September 10, 2001 8: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>