[xquery-talk] Finding a XML-Database to fit our needs

Fiebig, Thorsten Thorsten.Fiebig at softwareag.com
Mon Dec 17 17:52:46 PST 2007

I'm one of the Tamino XQuery developers. From my point of view Tamino would be a nice fit for your requirements. It is not free but we have a lot of customers who are using Tamino's native XML support on databases up to the terabyte range. Currently a new version is under development, featuring enhanced SOA capabilities. I think it is definitely worth to have a look at the Tamino homepage to get some more information.

Thanks & Regards,

From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf Of Johan Mörén
Sent: Samstag, 15. Dezember 2007 16:30
To: talk at xquery.com
Subject: [xquery-talk] Finding a XML-Database to fit our needs

Hi all,
I'm new to the list and work for a company in Stockholm, Sweden. 
We are currently evaluating a move from storing our data in a RDMBS (Oracle 10g) to storing it as native XML. The reason for doing this is that all communication to the persistence layer is done via SOAP and we believe we can save a lot of effort and time if we persist our data in the same format as we communicate it to the outside world. 
We are looking for a solution that can handle approximately 16 000 000 documents ranging from 50 to 200 KB in size. About 5k to 20k documents will be updated daily. The documents are all derived from the same base type and are described by a common schema. There are 5 sub-types that could be split into different collections where the largest, in terms of number of documents, would be about 8-9 million in size. 
Practically all documents have relationships described to documents belonging both to their own type but also to the other types so navigation of these relationships must be possible for querying purposes. 
The documents are very data centric, containing very little free text. But some fields will need to be backed by a free-text-index for querying. Since operators will work online with the data, query times will need to be reasonably fast for not to complex queries. 
Apart from the above. The database should support:
* Concurrent inserts and updates.
* XQuery 1.0 support.
* Any fragmentation of the documents (to handle the size) should be transparently handled by the database. 
* Both commercial and open source alternatives are of interest.
Any input, experiences and pointers on where to look would be very much appreciated.
"You can't always write a chord ugly enough to say what you want to say, 
so sometimes you have to rely on a giraffe filled with whipped cream." - Frank Zappa
Software AG - Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany, - Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/ Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David Broadbent, Mark Edwards, Dr. Peter Kürpick, David Mitchell, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/ Chairman of the Supervisory Board: Frank F. Beelitz - http://www.softwareag.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20071217/5cabe73d/attachment-0001.htm

More information about the talk mailing list