I have lots of statistical reports, each of them contains about 20000 records or more. GUI dispaly these results by paging with 1000 records one page, so when server calculated the results by using data from db, the server should stored the results in db/memory/file to support paging. These methods will not so good when there are lots of requests from GUI. Is there another paging strategy to solve this problem. Any help will be appreciated!
Asked
Active
Viewed 1,050 times
1
-
For *displaying* the pagination links, see here:
1 Answers
0
well, for the paging , you can use the startRow and endRow to narrow down the range. Also indexing that columan can accelerate your query. If your application upate the data in db frequently, it's not a good idea to save the query result in cache as most of them will be outdated soon. One way to resolve the high concurrent scenario is using connection pool.
Ivan
- 736
- 6
- 16
-
what GUI displayed are results calculated by server, not the data from db.Is there a good to paging the results?Thx – Michael Wu Jul 04 '11 at 06:55
-
@Michael, For your scenario, I suppose customer can accept the latency, then suggests are 1. Don't to calculate all paging data for one request. For one http request, pull start-end row number from request object, calculate it and just return these rows 2. If the request is heavy and it's better for you to consider cluster and load balance. – Ivan Jul 05 '11 at 05:40