RE: [xml-dev] XML Database vs. OO Database

["Chris Parkerson" <cparkerson@ipedo.com>]

Mike:

[shameless self promotion and correction]
Ipedo is not an "in-memory database."  It is a home-grown hierarchical
database, written entirely in Java, optimized for managing XML data.
The "in-memory" component is our patent-pending in-memory indexing
technology which, in essence, maps both the index and the data the index
references into highly optimized in-memory data structures.  Persistence
of XML is in our proprietary XML database, not a RDBMS.  We integrate
with RDBMS systems utilizing our Integration Manager which supports
bi-directional synchronization between Ipedo and RDBMS systems.
[shameless self promotion and correction ends]

Cheers,
Chris
 
Chris Parkerson
Product Manager
http://www.ipedo.com
Direct (650)306-4027
Fax    (650)306-4001

-----Original Message-----
From: Mike Champion [mailto:mc@xegesis.org] 
Sent: Sunday, May 19, 2002 8:54 AM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] XML Database vs. OO Database


5/19/2002 10:15:53 AM, "Joseph Barnes" <JBarnes@reallysi.com> wrote:


>  Hey listees, Can anyone point me to an intro level resource (web or 
> print)  describing the differences/ benefits between implementing a 
> native XML  database and an OO database?

Some good starting points are
http://www.xml.com/pub/a/2001/10/31/nativexmldb.html
http://www.rpbourret.com/xml/XMLDatabaseProds.htm
http://xml.apache.org/xindice/FAQ
http://www.eaijournal.com/PDF/StoringXMLChampion.pdf [shameless self
promotion]


I personally [not sure what the official corporate position is these
days] suspect a misunderstanding -- "native XML" now means that the
logical 
database model is XML, so users don't have to think about mapping XML
data to some underlying storage model.  That storage model could be an
RDBMS, and OODB, or something designed for XML.

So, there are a couple of ways to look at this question:  Perhaps you're
asking whether it makes more sense to store your Java objects natively
in an OO datbase as opposed to serializing them in XML and storing them
in an XML database?  Perhaps Excelon/ObjectDesign has some information
on this, since they support both scenarios.  In general, though, the
"native" XML approach has the same advantages and disadvantages of XML
itself: platform independence, vendor neutrality, universal support on
one hand, some loss of efficiency in the serialization/parse on the
other.

Or perhaps you've already got XML data and are asking whether 
it makes more sense to use an XML database with an underlying storage 
system that is optimized for XML
(e.g., Tamino or Xindice) vs one that is built on an OODB (Excelon), an
RDBMS (B-Bop) or an in-memory DB/RDBMS cache (Ipedo).  [BTW, this is 
my best understanding of these products, somebody correct me if I'm
wrong] I doubt if there is a one-size-fits-all answer here.  First, the
degree to which the underlying storage model is really optimized for XML
is a proprietary technology / trade secret of the vendors.  Second,
there are no standard benchmarks, and anyone can define tests to make
themselves look good.  (E.g., in-memory databases are REALLY fast as
long as you have less data than memory; powerful indexing schemes to
improve the speed of complex queries usually require more time when 
instances are inserted, etc.). The only benchmarks that should be taken
seriously at this point are those designed to match the 
hardware, data volumes, data types, and usage patterns of a 
specific installation.

Or perhaps you have lots of RDBMS data and want to import/export XML?
That's a whole different scenario .... the XML-enablement features of
your RDBMS system might be well-suited to your needs, or your increasing
needs to handle XML may quickly overwhelm them, or you may find it
useful to setup a native XML database in the "neutral zone" between
diverse RDBMS systems with incompatible XML features.  

Anyway, the point of all this rambling is that you're asking a 
question with no straightforward answer.