- From: Steve Harris <steve.harris@garlik.com>
- Date: Sat, 21 Aug 2010 18:09:44 +0100
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: Axel Polleres <axel.polleres@deri.org>, Paul Gearon <gearon@ieee.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 2010-08-21, at 16:18, Andy Seaborne wrote: > On 13/08/2010 11:22 AM, Steve Harris wrote: >> On 2010-08-13, at 09:59, Axel Polleres wrote: > >>> Just for comparison... this is how that would work in SQL ... assume I have the >>> knows relation in a table KNOWS(A,B): >>> >>> SELECT A,B FROM KNOWS k1 WHERE B IN (SELECT B FROM KNOWS k2 WHERE k1.A=k2.A LIMIT n); >> >> That kind of subquery isn't really equivalent, but SQL subqueries work bottom-up, like SPARQL: > > The interesting thing about Axel's SQL query is that it uses an outer reference (SQL terminology) where k1.A is referring to a column outside the ()-SELECT. > > Evaluation is defined as: > """ SQL-92 > 2) Each <subquery> in the <search condition> is effectively exe- > cuted for each row of T and the results used in the application > of the <search condition> to the given row of T. If any executed > <subquery> contains an outer reference to a column of T, then > the reference is to the value of that column in the given row of > T. > """ > > but I'm not immediately clear from that what happens in the SQL equivalent of nested optionals as I read it as saying the <subquery> > is (logically) executed for every row of the outer query with the outer reference bound to the value in the outer query. Ah, that's interesting - I'd missed that when I read the section on subqueries, so at least one part of SQL is explicitly top-down. Hmmm. - Steve -- Steve Harris, CTO, Garlik Limited 1-3 Halford Road, Richmond, TW10 6AW, UK +44 20 8439 8203 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Saturday, 21 August 2010 17:10:20 UTC