On 2010-10-19, at 10:31, Olivier Rossel wrote: > Thanks for all your comments. > I am now wondering about a few things and would appreciate your feedback: > > the use case I present is, in my opinion, very classic. > Most UIs dealing with a big set of data display them in a page-based manner. > > Steve proposes the application layer to handle the mismatch between > the LIMIT/OFFSET > queries and the page-based UI. > > If the only usage of the application layer is to refactor result > sets'rows into page-based UIs, then > an interesting alternative is to include the page-based query feature > in the SPARQL spec. > Any opinion? I think it would be hard to specify. That doesn't mean it shouldn't be done of course. (Arguably) the most obvious fix would be to have some way of writing a top-down subquery, but that has issues around the execution complexity of the resulting query, as I understand it. > What could be the technical issues of such a proposal? > As far as I understand, it is just an alternative way for the DB to > count the number of data > to return. Not a big deal, it seems, and it would avoid some tricky > coding at the application layer. > > > PS: I think SQL does not provide any better alternative, beyond > (tedious to write) subqueries. True? Subqueries in SQL aren't sufficient, they have the same execution rule as SPARQL. You'd need stored procedures, or a complex multi-stage query using temporary tables. There are tricks that can be done with GROUP_CONCAT, but it's non-standard (in SQL), and only works for some limited cases. - 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 9ADReceived on Tuesday, 19 October 2010 12:56:22 UTC
This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:20 UTC