On Fri, 14 Jun 2002 23:53:28 +0900, Christopher Browne wrote:
> Oops! Tobias Reif <tobiasreif / pinkjuice.com>  was seen 
spray-painting
> on a wall:
>> Austin Ziegler wrote:
>>> But I find that it's next to impossible to query intelligently
>>> in either an XMLDB
>> Might be true for some people ...
> You're missing the point.

> The hype of XML is that you can modify what's in the document
> structure; it's got all sorts of good, crunchy metadata so that 
that
> should work out very nicely.

And it is VERY good at representing hierarchical structured data. A
common example for XML is the address book. It's great for
representing that, but there are often relationships between entries
which don't fit into a hierarchical model, and trying to represent
them turns the document into a minor nightmare.

> If you change the hierarchy of the database, all the code written
> for the old hierarchy will have to change to reflect the new
> hierarchy.

This is so, and why I don't like XMLDB and OODB systems. In my
experience, data has value *outside* of how it is manipulated in a
particular program. If the data is forced to be structured in a
particular way because you've chosen a particular object model and
that model is replicated in your data store, it is often difficult
to turn that data upside down and look at it a different way. The
classic example here is that of orders and details; an invoicing
application only cares about orders from the order down to the
detail. An inventory tracking application, however, doesn't care
about the order, but the details. If your data is stored in such a
way as to require that order details are accessed through the order
itself, your inventory tracking application is going to perform as
slowly as molasses in January in Iqaluit, Nunavut.

> The point isn't of whether you can create a query; it's of whether
> you can create a query that will still work after you reorder the
> fields or move a field to a different level of the ODBMS
> hierarchy.

As I noted above, it's not just about the ability to reorder the
fields, but to be able to access the fields through multiple
navigation paths. Relational databases, for all of their faults,
tend to allow for easy navigation from almost any direction -- even
if the database is badly designed. Certainly, the problem of
marshaling objects is a problem, but it's not insurmountable.

> The issues aren't all that different from using relational
> databases, except that with relational databases, you don't
> normally get forced into writing code involving specific database
> navigation strategies.

This is also true.

That said, OO is a great way of conceptually dealing with data when
it's *active* (that is, in a program), and XML is a great way of
dealing with data exchange, but I don't think that either one is
particularly well suited to data storage per se, primarily for the
reasons I've outlined above.

-austin
-- Austin Ziegler, austin / halostatue.ca on 2002.06.14 at 11.36.33