[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Database Decision Tree?
"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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|