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

[Ronald Bourret <rpbourret@rpbourret.com>]

"Champion, Mike" wrote:
> 1) Storage: "decomposing the XML document to persist it to a relational
> database is not all that difficult" -- I have a one-word answer: "DocBook?".

Doesn't count. DocBook is document-centric and the article states
several times that it is considering whether to use native XML databases
for structured data. It also states in the side bar that native XML
databases are a good choice for documents.

(The article should really have been titled "Native XML databases: a bad
idea for *structured* data?" I read right over the statements saying he
was only considering structured data my first time through.)

> 2) Retrieval: "some of the native XML platforms require that the entire
> document be returned from the database"  Uhh, which ones?

He's probably referring to TextML here. However, TextML is a pretty
special case. It's designed as a document repository rather than as a
full-blown native XML database. I'm pretty sure that all the other
native XML databases can return fragments.

Other comments:

"However, decomposing the XML document to persist it to a relational
database is not all that difficult; it will provide benefits when you
start looking at the other functionality you want to support."

I agree with the second part of this sentence, but the first really
depends on the size and complexity of the document. I've seen DTDs with
hundreds of elements and figuring out a useful mapping from them to the
database is distinctly non-trivial, especially when a lot of the
elements are wrappers that don't represent real structure in the
database.

"Other native XML platforms decompose XML documents before persisting
them to the repository, but this tends to be a little clunky if you have
a complicated document structure (as many structured data XML documents
tend to have)."

Can't say I understand what is meant here by the "little clunky" bit.
Native XML databases define a model for an XML document and then store
the document according to that model. The model is the same for *all*
XML documents -- that's why native XML databases work. This statement is
actually more true for XML-enabled databases, where the complexity of
the mapping depends on the complexity of the data stored in the
document.

"Other native XML databases simply index all the information in a
document when it is added to the repository, which, as you might
imagine, causes the storage space required for a document to skyrocket
(imagine indexing all of the columns in a relational database!)."

This appears to depend on the indexing scheme of the database. Some
native XML databases claim very low multiples in document size. (If I
remember correctly, Neocore claims that storage space is less than twice
document size.)

That said, I do tend to agree with the article. Relational databases are
generally a better way to store highly structured data. Then again, most
native XML vendors I've talked to say the same thing, although nobody is
quite sure where the line is going to be drawn.

-- Ron