On Fri, Oct 7, 2011 at 1:17 PM, Roger Binns <rog...@rogerbinns.com> wrote:
> On 07/10/11 09:52, Simon Slavin wrote:
>> "Do you really want to see all 50,000 entries that that search would
>> return ?".  If this kind of search returns more than 100 records,
>> there's no point in doing it at all.
>
> You can solve this at the user interface layer and there is no need to
> calculate how many matching records there are.
>
> Lets say you can show 50 results on the screen.  Run the query but leave
> it open until hitting the 51st result.  Show the 50 results on the screen
> with a More button.  Most of the time the user will realise their query is
> too broad and change it, or see the values they were looking for.  If they
> hit next you can get the next 50 results which will allow you to know if
> you should show another More button.  Heck you can even show page numbers
> to 10 like Google does and if they get clicked on keep advancing the query
> through the results.  If the user clicks on page 10 but there are only 7
> pages of results then update the user interface to show page 7 and get rid
> of 8, 9 and 10.

The problem is you need to reap state in the case of the user
abandoning this "session" without telling the application.  This
happens all the time in web apps.

If there was a way to serialize the state of a SQLite3 VM...  then the
server could encrypt it and send it to the client as a cookie, say.
But that's not possible, and rather ugly.  Better not mention that
again :/

You could add OFFSET/LIMIT to the query and add those to the "next"
URLs.  But for many queries this doesn't really help.  Another
possibility is to combine this with what you propose next so the user
doesn't feel the pain, but the server still would:

> A different approach is infinite scroll.  As the user hits the bottom of
> the currently shown results you append more results in the display.

Definitely doable with JavaScript.

For web UIs you could also limit the queries to canned ones whose
results can be cached or better estimated.

Nico
--
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to