Re: [Exist-open] Design question on collections and documents

[Adam R. <ada...@de...>]

On Fri, 2007-11-16 at 14:47 +0000, WISE, Jon wrote:
> The possibilities are becoming clearer - thank you for your enthusiasm
> for my project. We at University of Gloucestershire do not teach XML
> database as a specific topic but XML features in web development courses
> and it is good to be familiar with developments.

Nice. Well if you want to learn more I would be happy to come and visit
the Uni for a day as I did with UWE.

> For the specific data we have been discussing, a relational database
> would probably be more appropriate but I am looking towards displaying
> the information on a web site and want to prepare and store fragments of
> XML and SVG which summarise the raw data so the web server has just to
> assemble a set of these fragments to create a full page. This seems much
> better than a conventional approach that would probably generate all the
> XML/SVG on every access. The XML/SVG storage fits very well with eXist
> and hence I did not include it in my original question. It is
> interesting to see if the newer technology will provide storage of both
> the raw data and the summaries.

So presumably an XSLT to transform the XML fragments into a XHTML page?

> With respect to your Solution A, the question seems to be whether
> recreating a (fairly) long XML document is appropriate for adding each
> new reading. Holding most of the data as a few long text strings feels
> wrong but maybe eXist copes with this and I should accept it. Presumably
> there is locking to cope with concurrency. What happens if XQuery update
> fails during the insert - is all the document lost?

You dont need to recreate the document for each update, by using XUpdate
or XQuery Update Extensions you can append/insert new readings into the
existing document.
I dont understand what you mean by holding the data as `long text
strings`?
Yes, eXist provides locking transparently to ensure correct concurrency.
If an XQuery update fails then nothing is lost, the document remains as
it was before the update. eXist uses a Transaction and Journal mechanism
internally to try and ensure ACID.

> Solution B makes the addition of new data a simple insert, which feels
> more natural, but the scaling problem changes from long documents to big
> collections. Your final search example demonstrates that the 'parent'
> path across a collection is possible but rather awkward.

Well the awkward relationship could be modelled in several other ways
that are more pleasing, but for the sake of keeping things simple I went
with that here.

Well big collections vs. long documents, its a performance trade off,
one is better for queries, the other for updating/removing.

> Thanks for the help.

My pleasure :-)

> Jon
> 
> -
> This email is confidential to the intended recipient. If you have received it in error please notify the sender and delete it from your computer.
> 
> The University of Gloucestershire is a company limited by guarantee registered in England and Wales.  Registered number: 06023243.  Registered office: The Park, Cheltenham, GL50 2RH
> -
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open