Physical pagination vs. logical pagination

Author: gianni.sandigliano@unifacesolutions.com (gianni)

Pagination as of today is implemented at DBMS level; it means we are managing parameters able to paginated data retrieved from DBMS itself. We call this feature "physical pagination". In many applications we need to use complex filters options, de facto discarding occurrences coming from DBMS with physical pagination configured. We call this feature "logical pagination". When logical pagination MUST be put in place because of application pre-requisites it is difficult to mantain stable the number of records presented on each web page. Question for Unifacers around the world: is the use of an intermediate temporary table the only solution to be able to show to the end user a fixed number of occurrences in each page? Thanks for any answer/tip/trick... :-) Ciao, Gianni

3 Comments

  1. gianni said In many applications we need to use complex filters options, de facto discarding occurrences coming from DBMS with physical pagination 

    Ciao Gianni, let me well understand...when you use this kind of filter, your app apply the filter to the result set in memory? Why you don't inject the parameters directly in your RDBMS's query? Ciao Claudio


    Author: Claudio (claudio.palladini@cortislentini.it)
  2. Claudio said
    gianni said In many applications we need to use complex filters options, de facto discarding occurrences coming from DBMS with physical pagination 
    Ciao Gianni, let me well understand...when you use this kind of filter, your app apply the filter to the result set in memory? Why you don't inject the parameters directly in your RDBMS's query? Ciao Claudio  

    Hi Claudio, reasons to use discard on the recordset coming from RDBMS are related to complexity. When complexity can be reduced into a single query we are happy to do it: - adding further selections into the main query - using more or less complex views ...but it isn't always possible because: - the query or the view can become TOO complex and slow! - the selection must work on a computed field using primitives from N entities Sometimes discarding in a later stage become the best choice available... Hope it is more clear now... Ciao, Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  3. Hi Gianni, there is my old concept on: http://unifaceinfo.com/forum/uniface9/paginationproblemsolvedbyproperdatapreparation/#p2337388 One can use a STANDARD multi-purpose table, if we put a uniface list of the key=values and store it in a single field. It can be made pretty flexible and it is very fast because the re-retrieve with all keyfields is a direct access.


    Author: ulrich-merkel (ulrichmerkel@web.de)