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

[Soumitra Sengupta <soumitra@b-bop.com>]

Bill Lindsey pointed out couple of things that I should have paid more attention
to.  Michael Rys pointed out another.  Sorry Michael.

My response was very wordy and lacks clarity.  Sorry about that Bill.  Will try
harder next time.  I am already getting better by working with you :-))

Second, there is a factual error in my response.  We are working with a professor
from an academic institution and not with the institution.  Sorry again.

But back to the alphaworks article.  I missed one point Kevin makes in his article.
Here is what he says:

"decomposing the XML document to persist it to a relational database is not all that
difficult".  As Dan points out, you can always store it as a "graph (two columns for
the edges, the third for the labels and/or data values)".  This was suggested by
Florescu and Kossman.  Now comes the problem.  How do you construct a specific
element without many self-joins.

This is partially true.  I think any smart DBA can come up with a schema for doing
this.  But putting it into a relational DB is easy.  How about making it usable so
that:
a. You do not have to alter that schema every time a new document type is thrown at
you
b. A usable schema that supports mixed content is non-trivial unless you store the
XML as a CLOB or a BLOB
c. You can retrieve the document using XPath or XQuery (once it becomes a
recommendation)
d. Reconstructing fragments
e. Performance
f. Scalability
I have seen at least 2 posts in this group before that describes a solution to this.

As Mike points out, try Docbook.  Once you have a solution for this on a RDMS, try
storing a NITF, XHTML or xCBL document without redoing everything.

So you see it is not all that simple when you are trying to build a solution or a
product that will stand deployment.

Regards,

Soumitra