Why XML Over the Relational Model?

[Simon St.Laurent]

[I've dropped the cross-post to xlxp-dev because this is a pretty straight
XML issue.]

At 07:24 PM 1/3/99 +0000, Dan Holle wrote:
>>>The primary answer I give this question is flexibility, though there is a
>>>significant cost in efficiency.  XML documents can easily hold structures
>>>that make relational databases choke. . . .
>>
>>I would love to see an example of this.
>
>Me too, Paul.

The simplest case is when your data store is keeping a bunch of documents
for you, be they memos, lab notebooks, or documentation.  While you can
store documents in RDBMS systems, it... well, it kind of sucks, even on a
good day.  If you happen to be lucky enough to be dealing with the portion
of data that all fits neatly into relational structures, without needed to
build messy scaffolding around it, XML probably isn't that exciting.  For
those of us who would like to perform complex operations on documents and
other information that doesn't fit relational systems neatly, XML is
revelation.

>Let's not think of XML as a representation for a complex multi-table
>multi-user shared database.  DOM, as a database, is like a RAM-resident
>single user IMS/DB.  (If you must barf, don't barf on your keyboard.)  There
>is a reason why we fled from hierarchical linked databases to relational.

Plenty of reasons.  But there is also lots of data - I'll retreat to
documents if I must - that fits a lot better into a managed XML environment
than a relational system.  And there's plenty of development on the object
store front that makes this a lot easier and more efficient than it has
been.  It makes relational purists irritable, but the rest of us can find
the tools we need to do our jobs right.

>Yes, there are databases you can do in XML that you can't do in relational.
>Just as  there are things you can do in assembler language you can't do in
>Java.  But if you are trying to do something useful with large, complex
>data, stick with relational.

As noted above, it depends on the kind of large, complex data you've got.
If it's cash register records for stores across the country, a relational
system is ideal.  If it's lab notebooks for a major pharmaceutical company,
stored alongside company memos, budgets, and other supporting documents,
you probably want something else.

>XML seems a good match for small but flexible structures on web-connected
>clients.  David's comments, saying XML is for information exchange and
>relational is for storage/query, rings true...

There are a lot more factors than just scale involved, and I suspect you're
going to find a lot more hierarchical storage/query/processing systems
getting built now that there's a decent standard (XML) to use as a
foundation.  Flexibility matters, and I think it will matter even more if
we have any hope of putting the 80% of business and other information that
lives outside of relational systems into any kind of reasonable
computerized order.

If the data is a good fit for a relational system, use an RDBMS.  If not,
look for something else, and look closely at XML.


Simon St.Laurent
XML: A Primer / Cookies
Sharing Bandwidth 
Building XML Applications (February)
http://www.simonstl.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)