RE: XML versus Relational Database

[Frank Richards <frichards@softquad.com>]

Linda,

Despite this weeks little flare up, your message fits well within the
established constraints of xml-dev.

It is not and never has been an open-source list, and technical discussion
of the solutions you know best has always been acceptable.

Frank

> -----Original Message-----
> From: Linda Grimaldi [mailto:grimlinda@earthlink.net]
> Sent: Thursday, February 01, 2001 11:31 AM
> To: Benjamin Franz; Caroline Clewlow
> Cc: Dream Catcher; xmlschema-dev@w3.org; xml-dev@lists.xml.org
> Subject: RE: XML versus Relational Database
> 
> 
> 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
> 
>