RE: XQuery updates [corrected subject line]

> 
>   I am really interested in the update, modify and delete 
> aspect of XQuery. Could someone provide some pointers as to 
> how existing products implement those features.
> 
>   My questions (which I am looking for some kind of references):
> 
>   (1) Assuming XQuery is built directly on top of native XML 
> datatype, instead of DBMS form of storage, how do update, 
> modify and delete of individual data fields impact the 
> performance of database?

Firstly, "native XML" and "DBMS form of storage" aren't alternatives.
The distinction is between a DBMS storage mechanism optimized for XML
and one that is optimized for relational tables.

I don't think it's possible to give a quantified answer. What one can
say is that (a) a system that permits node-level updates will carry
overheads compared with a system that does not (for example, retrieving
nodes in document order becomes more difficult), and (b) these overheads
can be significantly reduced if the storage structure is designed
explicitly for XML, compared with using a general-purpose table
structure.
> 
>   (2) Do any Xquery implementations offer features that allow 
> one to extract/remove an element in its serialized format?

Yes, I think this is a common feature.
> 
>   (3) Do any Xquery implementations allow one to splice 
> together new XML document from multiple other documents? Or 
> the reverse of it, which allows one to quickly take apart a 
> big XMLdoc into multiple smaller ones?
> 

You may find that some of these things are better done in the client
application, even if the Query engine does support it. For example, in
Tamino it is definitely better to assemble a complete document in the
client (for example, using XSLT) and then submit it to the database as a
unit, rather than creating it in the database using a sequence of
node-level updates.

Systems also differ in the ideal granularity of a "document". Tamino,
and several other systems, are optimized to store large numbers of
small-to-medium sized documents. Trying to store all your data in one
terabyte-sized XML document does not work well in such products. So it
may be better to store the "component" documents separately.

Michael Kay

Received on Friday, 30 January 2004 06:13:26 UTC