[
Lists Home |
Date Index |
Thread Index
]
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.
|
