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 versus Relational Database

----- Original Message -----
From: "Jay Zhang" <jz@intermicstech.com>
To: <xml-dev@lists.xml.org>
Sent: Monday, February 05, 2001 6:10 AM
Subject: Re: XML versus Relational Database

> I have serious doubt that a native XML database, however well
> designed it is, can succeed in commercial space, and ultimately
> as a viable technical solution. Look at OODB, no matter what
> reason you attribute its failure to.

So why do you really think that a native XML database can not possibly
succeed? You must have a better argument then simply saying that since
OODBMSs failed so must native XML databases? Storing XML data is a very
different problem and I really hope that people continue to exercise their
creativity in coming up with solutions to solve that problem. I don't think
anyone is saying that native XML databases are going to take over as the
dominant database mechanism for all application types. However, for storing
XML data they might actually make a lot of sense and really shouldn't be
dismissed out of hand. If your measure of success is going to be whether or
not native XML databases become the dominant data storage mechanism then you
are probably right they most likely will not achieve that goal. Fortunately,
that has no relation to whether or not they can succeed in the commercial
space. I certainly prefer to see people trying and to let the market decide,
in 10 years or so we can then look back and see how things ultimately shake

> Why don't we focus our energy on implementing XML data structure
> on a relational database and map all desired features to RDBMS
> features? I love to see a standard like that.
> We can definitely map the tree structure of XML into relational
> database and store an offset (of the element in the blob) going
> with the element, ..., blah, blah. As long as the XPath
> navigation can be efficiently supported, I guess other features
> would not be such a hard thing.

The funny thing here is that what you are describing is very similar to how
some native XML database vendors are approaching the problem. I think you
are failing to understand what a native XML database really is. I refer you
to the definition published by the XML:DB initiative that might clarify
things some what.

"Native XML Database (NXD) - A database fundamentally designed to store and
manipulate XML data. Data access is through XML and related standards e.g.
XPath, XSL-T, DOM or SAX. This includes all databases where the underlying
data representation maintains the full XML structure and associated
meta-data. The underlying data storage format (e.g. Object database,
relational database, or other) is not important and access to the data
storage by means other then XML related technologies is not allowed. The
fundamental unit of storage in an NXD is an XML document. Tamino, dbXML and
X-Hive all fall into this category. "

This is taken from http://www.xmldb.org/faqs.html.

> The so-called multi-dimensional database is so well fitted in
> Yes, it takes up much space. Storage is cheap, isn't it?
> Jay Zhang
> IntermicsTech, Inc.

Kimbro Staken
Chief Technology Officer
The dbXML Group L.L.C.