- From: Arkadiusz Binder <Arkadiusz.binder@rip.org.pl>
- Date: Tue, 19 May 2015 10:20:38 +0200
- To: Michael Kay <mhk@mhk.me.uk>
- Cc: Yoonmoe Lay <yoonmoelay@gmail.com>, "www-ql@w3.org" <www-ql@w3.org>
- Message-Id: <E6FE4CCC-1CF3-4E8F-BD94-3A35B5B9B28B@rip.org.pl>
We are doing similar subject. Is there a technology of using Saxon on server side with optimized querying big xml files or xml collections in folders, where the data could be cached and reindexed incrementally (based on updated files). If I have many different queries with using big (above 1Giga) xml - then I could move to native xml files only if the second query to such xml will not load it again to memory. We are also doing some progress of transforming Xsd schema to remap objects to small xml files or api calls. We found about 12 conditions of transforming XSD ( e.g. where to instance many derivations) - at the moment : read(schema, prefix:element, xpath) gives XML; write(schema,XML) writes . Now we are doing this interactive JavaScript form which will honor Xsd choices, references and occurs. We couldn't find any solutions with remapping Xsd to flat database tables. Can I find somebody near this subject? -- Arkadiusz Binder Stowarzyszenie Rozwój i Praworządność > On 18 maj 2015, at 22:08, Michael Kay <mhk@mhk.me.uk> wrote: > > You may be using the open-source Saxon-HE implementation, which does not have a join optimizer; joins are a great deal faster in the commercial Saxon-EE implementation. > > However, all SQL implementations that I know of run on persistent data in a database, and joins usually perform best when you have pre-built indexes on the relevant data fields. There are many XQuery implementations designed to run on a database environment with a similar approach to indexing, and I would expect them to perform equally well. In this respect Saxon is different because it works on ad-hoc XML data files, with no opportunity to build indexes manually in advance. Although Saxon-EE uses indexes to optimize joins, it has to make the indexing decisions itself based on the actual query. > > Also, I think the equi-join operation is a lot less important when dealing with hierarchic data (XML) than when dealing with relational data (SQL). Most of the time with XQuery, the relationships you need to use in a query are the hierarchic relationships implicit in the XML, rather than value-based relationships between primary keys and foreign keys. The focus in an optimizer is always on optimizing the constructs that are most used. > > Michael Kay > Saxonica > > >> On 18 May 2015, at 18:48, Yoonmoe Lay <yoonmoelay@gmail.com> wrote: >> >> Dear everyone, >> >> I am a computer science master student from >> Myanmar. Now, I am doing analysis of querying system for SQL and >> XQuery. May I know why XQuery ( that used Saxon) is slower than SQL in >> Join queries? I want also to know why XQuery is faster than SQL expect >> Join queries. Please answer my questions as soon as possible. Thank a >> lot. >> >> Best Regards, >> Ms. Lwin Moe Aung > >
Received on Tuesday, 19 May 2015 08:41:35 UTC