|
At 09:45 PM 12/2/02, you wrote:
> Um, nobody looks at 5000 records at a shot, do they?
yes they do... In some pages is is 20 records at a time (like any search engine returns the 1st page as 1 of 2,000,000)
Yes, this I expect to see. And a 20 (or 50, or 100) records at a time, this is efficient and effective. 5000 records on one page seems wrong, in the general case.
In some I return the whole set in html, usually not more than a minute or 2 to load.
Why? Why not provide a page at a time? This seems wasteful. I have my google preferences set to return 100 at a shot, and I find that I will look through 100, or even 200 links, but 5000? No way. And why wait two minutes to see a screen. On the iSeries, my customers expect sub-second response. Not multi minute response.
Also provide a link to save the whole set in a .csv file from the ifs. They can use it in Excel.
Fine, I do this, too. But I can still provide a link to all the data, yet display one page at a time to the browser.
jim ----- Original Message ----- From: "Rich Duzenbury" <rduz@westernmidrange.com> To: <web400@midrange.com> Sent: Monday, December 02, 2002 7:14 PM Subject: Re: [WEB400] How to present large datasets on the Web? > So. Has anyone tried to routinely display a list that contains five or ten > >thousand entries on the web? What architectural approach did you take? > > --buck > > Um, nobody looks at 5000 records at a shot, do they? > > You need to invent a subfile mechanism - You know - 'get the next page of > records', 'get the previous page of records', and so on. Have your java > person call your program and give it a selected page number as a > parameter. Your RPG program locates that page of records and returns it. > > It would even be fun to add filtering and sorting capabilities - You know, > longest telephone calls, highest cost calls, and so forth. Resequence the > display by number dialed. > > > > Regards, > Rich >
Regards, Rich
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.