Optimizing queries for the next and previous element

前端 未结 11 916
耶瑟儿~
耶瑟儿~ 2021-01-30 11:33

I am looking for the best way to retrieve the next and previous records of a record without running a full query. I have a fully implemented solution in place, and would like to

11条回答
  •  日久生厌
    2021-01-30 12:03

    I've had nightmares with this one as well. Your current approach seems to be the best solution even for lists of 10k items. Caching the IDs of the list view in the http session and then using that for displaying the (personalized to current user) previous/next. This works well especially when there are too many ways to filter and sort the initial list of items instead of just 3.
    Also, by storing the whole IDs list you get to display a "you are at X out of Y" usability enhancing text.
    JIRA's previous/next

    By the way, this is what JIRA does as well.

    To directly answer your questions:

    • Yes it's good practice because it scales without any added code complexity when your filter/sorting and item types crow more complex. I'm using it in a production system with 250k articles with "infinite" filter/sort variations. Trimming the cacheable IDs to 1000 is also a possibility since the user will most probably never click on prev or next more than 500 times (He'll most probably go back and refine the search or paginate).
    • I don't know of a better way. But if the sorts where limited and this was a public site (with no http session) then I'd most probably denormalize.
    • Dunno.
    • Yes, sorting cache sounds good. In my project I call it "previous/next on search results" or "navigation on search results".
    • Dunno.

提交回复
热议问题