[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

HDBMS vs RDBMS (Was: Re: Storing Lots of Fiddly Bits (was Re: What is XM

• From: Clark Evans <clark.evans@m...>
• To: "XML Developers' List" <xml-dev@i...>
• Date: Fri, 05 Feb 1999 03:23:41 +0000

Jonathan,

First, I like what you wrote.  It makes sense to me.  :)

"Borden, Jonathan" wrote:
> 
> Comparing apples to apples, the DOM has elements and attributes, and a
> Recordset has rows and columns. Most bank accounts in the world today are
> well represented as rows and columns. There are times when the slightly more
> complex concept of elements and attributes has a better impedance match to
> the data being modelled than rows and columns.

This is, in essence, the debate of the 70's between the hierarchical
model (HDBMS) and the relational model (RDBMS).  The relational 
people "won", in part, beacuse they had a mathematical theory 
which formally defined how their database works.

I see MURATA Makoto's work as being the mathematical formalism 
required to explain how a hierarchical database would work.  This
to me is exciting.

If anything, I would say that any *reasonable* database in the
future must handle both and what would be wonderful to see
is a mathematical formalism that allowed both perspectives to
work in a complementary fashon.

Already, relational databases are adding hierarchical features,
witness the "CONNECT BY" clause in Oracle.  And, the hierarchical
people are busily adding relational features (XML Link).

I think the problem is that the data needs to be both viewed
as a set of relations _and_ as a hierarchy.   I feel that it
will be tempting to "toss out" relational theory in favor
of hierarchial databases.  I think the true solution will
involve some sort of "DUAL" which allows for a gateway
between the "world of sets" and the "world of trees".

Perhaps objects provide the language necessary to unify these
two different pictures of information.

>         Perhaps not yet, but if I want to automate transforms, XSL or the
> transformation language subset 'XTL' is a leap in the right direction. A
> large part of computer programming consists of interfacing one API to
> another. I'm not saying that XSL helps with this at all but pointing out
> that transformations and impedance matching is an important task. If we have
> the ability to express transforms directly this greatly reduces the need to
> do traditional coding and bit twiddling.

The XTL is, in effect, the equivalent of SQL for a relational database.

An SQL statement takes one or more relations and produces another
relation.  So true that XTL will do a similar thing to trees.

This is indeed very exciting.  After XTL is worked out, then
we only have two more transformations left, RDBMS->HDBMS and
HDBMS->RDBMS.  And neither of these is trivial.

Thoughts?

Clark Evans

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • RE: Storing Lots of Fiddly Bits (was Re: What is XML for?)
    • From: "Borden, Jonathan" <jborden@m...>

• Prev by Date: RE: Storing Lots of Fiddly Bits (was Re: What is XML for?)
• Next by Date: RE: Storing Lots of Fiddly Bits (was Re: What is XML for?)
• Previous by thread: RE: Storing Lots of Fiddly Bits (was Re: What is XML for?)
• Next by thread: Re: Storing Lots of Fiddly Bits (was Re: What is XML for?)
• Index(es):
  • Date
  • Thread