[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] XML Database Decision Tree?
- From: Soumitra Sengupta <email@example.com>
- To: firstname.lastname@example.org
- Date: Fri, 19 Oct 2001 13:24:38 -0700
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
a. You do not have to alter that schema every time a new document type is thrown at
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
d. Reconstructing fragments
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.