[xquery-talk] XQuery coding style: nested FLWOR expressions
John Snelson
jsnelson at sleepycat.com
Wed Apr 12 12:49:31 PDT 2006
I think there are definitely two camps of XQuery writers. Those that
have learnt XQuery because it is the "SQL of XML" are tainted by their
SQL background, and often don't realise that you can write an XQuery
statement without a FLWOR clause.
Those of us that approach XQuery from an XML, XPath and XSLT background
(myself included) are used to the ideas of the context item, inline
predicates etc.
I guess this is a symptom of the way XQuery was conceived, designed and
marketed. However, I'm not really sure that one way is arguably superior
to the other - query processors are just going to have to optimise both
methods to the same execution strategy, eventually.
John Snelson
Michael Kay wrote:
> I've been looking again recently at some of the XMark benchmark queries.
>
> I'm wondering what it is about the language that makes people write things
> like this (Q9):
>
> for $p in /site/people/person
> let $a := for $t in /site/closed_auctions/closed_auction
> let $n := for $t2 in /site/regions/europe/item
> where $t/itemref/@item = $t2/@id
> return $t2
> where $p/@id = $t/buyer/@person
> return <item> {$n/name} </item>
> return <person name="{$p/name}">{ $a }</person>
>
> when they could have written
>
> for $p in /site/people/person
> return <person name="{$p/name}"> {
> for $t in /site/closed_auctions/closed_auction[buyer/@person = $p/@id]
> return <item> {/site/regions/europe/item[@id = $t/itemref/@item]/name}
> </item>
> } </person>
>
> Is it just a torture test for optimizers? Did the author think this was the
> best/easiest way to write the query? Does anyone else think it is? Is it the
> way SQL users' brains are wired?
>
> Michael Kay
> http://www.saxonica.com/
>
>
> _______________________________________________
> talk at xquery.com
> http://xquery.com/mailman/listinfo/talk
--
John Snelson, Berkeley DB XML Engineer
Sleepycat Software, Inc
http://www.sleepycat.com
Contracted to Sleepycat through Parthenon Computing Ltd
http://blog.parthcomp.com/dbxml
More information about the talk
mailing list