RE: XML versus Relational Database

[Linda Grimaldi <grimlinda@earthlink.net>]

I've stayed out of this discussion thus far because my company has a
blatantly commercial offering in the XML "database" space and  I didn't want
to get all sorts of nasty mail about exploiting the list for commerical
purposes.  But I can control myself no longer. I truly believe that our
approach has done away with a lot of the problems with RDBMS and so-called
"native" solutions and I don't see anything out there that does things quite
the way we do.

What it boils down to is that RDBMs are a pretty gross way to store XML- you
lose flexibility, mapping is a pain, shoving complex hierarchy into a  set
of tables can be very inefficient, etc.- and DOM-based implementations tend
to be awfully piggish and painfully slow.  We have taken a pattern-based
approach to storing and retrieving XML data, and the result gives you all
the traditional "CRUD" capabilities (including the ability to insert new
structure into an existing document) in a transactional fashion (by May)
with very good performance, a relatively small footprint and complete schema
independence.

I really hope I haven't offended anyone- I apologize that the product isn't
free and I have mentioned its existence on this list.  But I really do
believe that it solves a lot of the issues people have brought up in this
thread  in a very elegant way and that it can help folks in their
implementations.

I'll be quiet now.

Linda Grimaldi
Vice President, Product Engineering
NeoCore, LLC



-----Original Message-----
From: Benjamin Franz [mailto:snowhare@nihongo.org]
Sent: Thursday, February 01, 2001 8:43 AM
To: Caroline Clewlow
Cc: Dream Catcher; 'xmlschema-dev@w3.org'; xml-dev@lists.xml.org
Subject: Re: XML versus Relational Database


On Thu, 1 Feb 2001, Caroline Clewlow wrote:

> Isn't the issue that XML is not designed as a mechansim to store data, but
a
> mechanism to allow data to be provided in a common format that can be
> understood by disparate systems ?
>
> ( I know this is a criminally simplistic view of what XML is about but I
> just wanted to make the point  :-)

This is an issue I just brought up on the XSL-LIST as 'Paradigm clash
between XML as document and as database'. People like myself see XML as a
description of a database structure with XML *files* themselves just being
a common import/export format. I see DOM, XPath and similar programmatic
APIs as actually more fundamental than the flat XML text files.

This difference in 'think' is why you see (what is to me) sillyness like
hardcoding stylesheet directives in XML datafiles when that is 3.141592
radians away from what *I* need to do - which is apply arbitrary different
stylesheets to common XML data. In my world, it approaches zero utility to
hardcode stylesheet callouts in the XML data.

The clash in paradigm is causing great pain for those of us who want to do
'great things' with XML because the 'XML database' vendors seem to have
come from the SGML worldview of a 'database of XML documents' rather than
the view of 'XML document as database'. This causes things like XSLT to
scale rather badly with every production level 'native' XML database I am
aware of today. All of them appear to have realized the 'error of their
ways' - but their solutions are still 6 months to a year out by their own
estimates.

Right now, the only *scalable* solution (ie in my case capable of handling
more than a megabyte of XML data being rendered to web pages in a
sub-second response environment on server class multi-cpu ix86 hardware) I
am aware of is XML mapped onto SQL. And a butt-ugly solution it is.

And *aggressive* caching.

--
Benjamin Franz

... with proper design, the features come cheaply. This
approach is arduous, but continues to succeed.

                                     ---Dennis Ritchie