RE: Against the Grain: Pascal commentary about XML and databases

[Joshua Allen <joshuaa@microsoft.com>]

There *are* database tools that take a more incremental approach, and
simply expose a relational structure as XML, so things like rollups
below are not necessarily a challenge.  This is the camp of people who
believe that XML is simply a "more loosely constrained relational
model", and who believe that XML databases must evolve from relational
and take advantage of the past 30 years of relational research.

On the other hand, there are good reasons to use a pure native approach
for XML.  The "native XML" people will be able to show you blazingly
fast queries over massive data stores that would make an RDBMS croak.
The "XML-adaptor" people will show you queries against *their* XML that
run blazingly fast but make a "native" engine croak.  The moral is that
there is no "one true way" at this point, and both models will converge.
I think it's a teeny bit unfair to call XML databases "snake oil";
instead think of 2001-XMLDB as 1980-SQL.  As "native" databases evolve
to support traditional relational-type stuff better and relational-XML
adapters evolve to support things that native implementations excel at,
the distinction will become irrelevant and the code bases will be pretty
much the same.  In the meantime, using XML databases means having a good
understanding of your use cases, needs, etc. and evaluating each product
individually.

Regards,
Joshua

> -----Original Message-----
> From: XML Everywhere [mailto:host@xmleverywhere.com]
> Sent: Thursday, June 28, 2001 3:33 PM
> To: Mike.Champion@SoftwareAG-USA.com; xml-dev@lists.xml.org
> Subject: Re: Against the Grain: Pascal commentary about XML and
databases
> 
> I know next to nothing about relational calculus.
> What I do know is that I tried to use
> "native" XML storage products in non-trivial
> ways and they failed.  Storing a document
> is one thing.  E.g., thousands of XHTML pages.
> That's trivial.  It's just a filesystem with
> some extra features.  Storing a database of customers
> and orders isn't.  The relational model allows
> data to be viewed in almost as many ways
> as is needed.  XML is a
> single-view paradigm that requires non-trivial
> technology to transform data.  By "non-trivial"
> I mean it takes excessive amounts of CPU
> and memory.
> 
> I get emails from sales people all the time
> trying to convince me otherwise, so
> I understand Pascal's lack of tact.  In
> most cases these emails come from
> those who have never stored
> 10 megs in a database and then have
> a user say "gee could you roll
> up the sales by category and month?"
> 
> There are a lot of suckers out there,
> and not having to worry about
> database design issues is
> certainly appealing.  Native XML
> databases are the new snake oil.
> 
> ----- Original Message -----
> From: <Mike.Champion@SoftwareAG-USA.com>
> To: <xml-dev@lists.xml.org>
> Sent: Thursday, June 28, 2001 2:44 PM
> Subject: RE: Against the Grain: Pascal commentary about XML and
databases
> 
> 
> 
> Someone tried to bring the
> existence of an XML database product to his attention, and got the
> response
> "This is a nonsensical statement. I wish there was a more delicate way
to
> respond to this, but unfortunately the only thing I can say is that
you
> really don't understand data fundamentals and you missed the point of
my
> article. People without a decent understanding of data fundamentals
should
> not be in the database business."
> ...
> 
> I keep hoping that there is some middle ground where the rigorous
> mathematics of the relational model and the pragmatic usability of XML
can
> meet and inform one another.  In private correspondence, Mr. Pascal
> assured
> me that a truly mathematical model of XML is impossible, but I'm
keeping
> an
> open mind.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------
> The xml-dev list is sponsored by XML.org, an initiative of OASIS
> <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xml-dev-request@lists.xml.org