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

[Leigh Dodds <ldodds@ingenta.com>]

> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@softwareag-usa.com]
> Sent: 18 October 2001 14:51
> To: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] XML Database Decision Tree?

[...]

> ... If you anticipate frequent queries on the actual
> document structure and content, a native XML DBMS may be more appropriate.

As well as considering queries, the granularity (and likelihood) of updates
ought to be considered. For example if an update will generally cause
a whole new version of a document, then replacing the entire content
each time is a good general approach. If editorial changes/revisions are
common, then some decomposition might be useful.

(The folks on the xml-doc list might have more to say on some of these
document storage specific issues).

> Which reminds me of another "rule" I'd suggest.

I'll add another one:

If you have 'data oriented XML', and the only reason you need XML is for
exchanging data between business partners, or systems. Then you don't
need an XML database. A plain relational database with appropriate import
and export routines will do the job admirably. (IOW use it when it's
appropriate).

This also gives you some freedom to allow you relational schema to be
organised however you like (assuming you're dba will let you :), whilst
giving
you the freedom to standardise on an alternate representation for
interchange. As well as the ability to support multiple interchange formats.

There might be something in here about schema evolution as well. However
I'm not familiar enough with native XML products to say how they'd
handle this.

E.g. if your schema is in a constant state of change (and they probably all
are
over time) or has yet to be finalized/standardised then locking it into a
database structure might be unwise. Or am I off track on that one?

L.