Implementing Search Result Pagination in a Web Application, Page 2
Middle-Tier-Driven Pagination Algorithm
Modern frameworks and database drivers allow efficient in-memory traversal of data on the application server level or middle-tier level. I would not recommend this approach for large data sets. However, because this approach could be combined with the caching solution on the application server, it should be considered for small to medium data sets. Depending on the nature of the business requirements, this solution could be used for "rigid" searches, where users have no control of the query parameters and are forced to use pre-defined criteria, such as a shopping category.
If many users can request an identical search query (and the result is not in the millions of rows or changes very often), it makes sense to select the whole result set from the database and pre-cache it in the application server's memory. Subsequent queries would not result in expansive database hits, and will be served very quickly from the application server's memory.
Front-End Pagination Algorithm
Here is the overview diagram of the third approach:
Generating Page Links
After choosing the best approach to retrieve the result set and traverse it, the application needs to create the actual page links for users to click. Below is a generic function pseudo-code, which should work with any server-side technology. This logic should reside in your application, and will work with both database-driven and middle-tier pagination algorithms.
The function takes three (3) parameters and returns HTML representing page links.
The parameters are query text, staring location row number, and total number of the result set rows. The algorithm is clever enough to generate appropriate links based on where the user is in the navigation path.
Note: I set the default of 50 rows per page, and a page window to 10. This means that only 10 (or fewer) page links will be visible to the user.
Page 2 of 3