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

[Nicolas LEHUEN <nicolas.lehuen@ubicco.com>]

This raises the following question : are there schema mutation tools in
native XML databases ? I.e. you provide a new target schema and the XSLT
stylesheet to apply to move one collection of document from an old schema to
the new one, and the database processes all relevant documents in a safe
way, e.g. by locking the collection or any other means that would prevent
clients to get a mix of old and new documents.

Regards,
Nicolas

>> Speaking generally, the native XML DBMS tend  to be more
>> flexible in handling data with no schema, or with evolving 
>> schema, than solutions based on normalizing XML into RDBMS tables.
>> 
>> Could you explain this further? The flexibility is easy to 
>understand,
>> but I'm having trouble seeing what it buys me. If I store my data 17
>> different ways, I'm going to have one heck of a time querying it.
>
>OK.  The various native XML DBMSs, by diverse means, allow 
>well-formed XML to be stored and efficiently queried without 
>demanding rigid adherence to a schema.  Some do this by never
>defining an XML schema at all or by storing well-formed XML 
>that doesn't
>match a known schema in a "miscellaneous" collection, some by 
>allowing the
>schema to evolve and re-indexing on the fly or whatever, some 
>by allowing
>open content models at any point in the schema, or by some combination.
>There is a bit of a tradeoff here -- I would guess (I am not 
>up-to-date on
>exactly how it works in the current Tamino, and obviously am 
>not privy to
>the details of the others) that it is generally more efficient 
>to search on
>structures that are rigidly defined. BUT given that  native 
>XML DBMS may use
>some sort of inverted list/associative memory/binary relation 
>internal data
>model for the XML itself not just the indexes, predictability 
>is probably
>not as big an advantage as one might think.  
>
>So, the example of a collection of XML instances whose schema that has
>evolved through 17 different iterations would not be a problem 
>at all in
>some of the native XML DBMSs, would not be a problem in Tamino in most
>cases, and in the typical case all 17 subsets would be stored 
>together in
>the "miscellaneous" collection where they can be queried with 
>reasonable, if
>not optimal, efficiency. The only time you'd have to query 17 
>different ways
>is if the top-level tag changed with every iteration of the 
>schema; so this
>is a worst case scenario involving a completely clueless set 
>of developers
>and DBAs.
>
>My larger point (as a couple of people have picked up on) was 
>that most DB
>developers do not control their own destiny with respect to 
>schemas -- they
>store the data someone tells them to store, and if the schema 
>changes, they
>deal with it.  Native XML DBMS developers will spend a lot 
>fewer nights and
>weekends "dealing with it" than those trying to store evolving 
>XML schema in
>an RDBMS.