Question

Some background

The system in question has some ten thousand records which the user is allowed to browse or search through a “massive” array of different search criteria. The result is then displayed in a paginated table ranging from a few pages to every result in the database.

If the user has made a lot of filtering and ended up with a result and clicks an arbitrary record she is then taken to a new view /edit/{record_id} where she can view all the details of said record. It’s easy to go back to the last search result at any time, as the criteria is retained in the search bar, but:

What I’m trying to achieve

If the user is to do a lot of changes based on the search result, it would be very convenient with previous and next buttons to access the adjacent records without returning to the result.

I’ve been able to do this on a basic level using ids

SELECT table.*, pn.p as previous_question, pn.n as next_question
   from table,
   (
       SELECT id, lead(id) OVER w as n, lag(id) OVER w as p
       FROM table
       window w as (order by id $order)
   ) as pn
   where table.id = $id
       and pn.id = $id

This obviously only works for the simplest of cases where the records are in the same order as in the database. What I want is for them to work in every case of data order. Needless to say, the are nearly infinite ways to sort this data.

What I’ve been thinking

Create some kind of function/tool that will let me keep the SQL from the search and perform it again like above, only with search criteria and offset in stead of ids

Save a list of the order of all the records in the result, either in the $_SESSION, database or somewhere else, and then simply traverse the list to get the ids I need.

Tools at hand

PHP, PostgreSQL, JS/jQuery.

TL;DR

I want to be able to get to the next search result without returning to go back to the search, no matter how many times the user clicks “next”.

———-

Any input would be appreciated. Links to relevant articles, ways to approach this or even the whole shebang ;). It would also be nice to be able to solve this without eating all the servers memory, or excess db access, although resources aren’t really an issue here.

Answer 1

I’m just going to throw it out there… You should use Solr or something similar particularly if this a SAS and exposed to many users.

Basically trying to keep track of a paginated search result and then traversing will cause lots of state management in your app.

The idea with Solr (or even just plain postgres) is to do a start and size for your search (aka OFFSET and LIMIT). Solr does this so fast its hardly a performance problem. Just make sure for Solr or Postgres you do a predictable sort by (aka ORDER BY).

If your worried about new items being added throwing off the pagination thats simply a: WHERE create time stamp is less than when we did the initial search.