[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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@n...] Sent: Thursday, February 01, 2001 8:43 AM To: Caroline Clewlow Cc: Dream Catcher; 'xmlschema-dev@w...'; xml-dev@l... 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|