[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML versus Relational Database
- From: Benjamin Franz <firstname.lastname@example.org>
- To: Caroline Clewlow <email@example.com>
- Date: Thu, 01 Feb 2001 07:43:26 -0800 (PST)
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
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.
... with proper design, the features come cheaply. This
approach is arduous, but continues to succeed.