- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Sat, 21 Aug 2010 16:18:26 +0100
- To: Steve Harris <steve.harris@garlik.com>
- CC: Axel Polleres <axel.polleres@deri.org>, Paul Gearon <gearon@ieee.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
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.
Andy
Received on Saturday, 21 August 2010 15:19:17 UTC