Hi all, We're planning to use an XML database for a model that we know will change often over time. Like today a <User> might just have a <Name> and <Address>, but in the future we might also require <Telephone>. We will also be updating the data itself a lot, using XQuery Update through the xqj.net drivers. I have read [1] that the number of distinct namespace URIs in BaseX is limited to 256. We were thinking to keep keep track of "releases" of our XSDs through versioning of namespaces, but then 256 seems too low a number. - Any smart ideas about this? Also, I wonder if it would be better to use many small documents, or use a single document that hold all the nodes. Like: <Users> with many <User> nodes, or just many <User> documents. And many <Review> documents, or a single <Reviews> holding many <Review> nodes. Or even one big <Data> document to hold both <Users> and <Reviews>. One reason to use many documents is because, as described above, we will have different versions/releases, which seems easier to maintain in multiple documents. I've seen Christian's research [2], but that does not cover updates. So: - Does anyone know of real life examples of one approach, or the other? - Would updating a small document be faster than updating a node in a larger document? - Would it matter if we update multiple documents, like both a <User> and a <Review>, in a single XQJ statement? Also, one of the developers of eXist-db once wrote [3]:

[...] there are certainly some practical considerations. Storing a very large document can block the db more than storing many small ones. It requires a single transaction (and sufficient disk space for the transaction log).

[...] I know other users have to deal with much larger documents (many gigabytes), but if you have a choice, I would definitely recommend to split your data in smaller chunks, which are easier to handle.

- Does anyone know if the same applies to BaseX? Any (other) input appreciated! Thanks, Arjan. [1] http://docs.basex.org/wiki/Statistics [2] http://kops.ub.uni-konstanz.de/bitstream/handle/urn:nbn:de:bsz:352-opus-1271... [3] http://exist-open.markmail.org/thread/byuzpoj7cyfmlqdo