RE: [xml-dev] XML Database Decision Tree?

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Jeff Lowery [mailto:jlowery@scenicsoft.com]
> Sent: Monday, October 29, 2001 8:30 PM
> To: 'Champion, Mike'; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] XML Database Decision Tree?
> 
>
 Although that may be more intuitive (to us) in an XML
> containment hierarchy than it would be in a set of relational 
> tables strung together with joins, there's still more than one way to skin

> a conceptual cat, even in XML. 

Sure.  The only point I was making is that figuring out how to represent an
arbitrary paper document as a hierarchy is a whole lot easier for the
average web developer than figuring out how to decompose it into tables and
recompose it with joins.  Once you've done even a plausible modelling job
that can be represented as well-formed XML, you can put instances in an XML
DBMS, get them back, update with transactions, etc.  You have to do a
reasonably *good* job of data modelling to be able to even store the data
represented in a simple document in an RDBMS and retrieve it back intact.

> 
> Same goes for performance tuning. If you don't have the right 
> properties collocated in the elements, you're going to have a lot 
> unnecessary document navigation to do. 

An XML DBMS does not *necessarily* perform queries by "navigation." That's
the point I was trying to make with the sermonette about Monet DB; it can
execute XPath queries by (very crudely) looking for matches between the
input query string and the stored element path summaries more efficiently
than a simple implementation that navigates paths. 

My point isn't that data modelling is pointless in an XML DBMS, just that
it's not absolutely necessary to do a serious data modelling effort in order
to do get a minimal DBMS application running. Likewise, the default indexing
scheme may do a pretty good job without any performance tuning, although an
informed analysis of the data model and the indexing strategy can generally
improve performance. All this can be VERY useful if you have more types of
data than you can model, but need to store, retrieve, and query instances of
them reasonably efficiently.