Re: About Saxon XQuery Processor

On Tue, 2015-05-19 at 10:20 +0200, Arkadiusz Binder wrote:
> 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).

You are wanting an XML-native database, I think; there are several of 
these, both open source and commercial. Some relational databases also 
include XQuery support.

> 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.

XML documents have hierarchy and sequence as native properties. 
Relational database tables have neither of these. As a consequence, 
relational databases tend not to be a good fit for modeling XML.

In specific cases, though, you could design an XML Schema Document to 
be easily represented in a relational form, or you could design an XML 
Schema Document so that XML instance documents that conformed to such a
schema could themselves be stored in a relational database. Without 
knowing what you mean in more detail it's difficult to answer your 
questions.

Liam

-- 
Liam Quin, W3C XML Query Working Group team contact.


> 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 Thursday, 21 May 2015 05:38:37 UTC