W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

Re: limit per resource rethought...

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Sat, 21 Aug 2010 16:18:26 +0100
Message-ID: <4C6FEE42.5000102@epimorphics.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:43 GMT