* Da Martian <[EMAIL PROTECTED]> [2006-10-25 14:15]: > 1) If there are too many results the user will have to wait > a long time before they see anything because we will be > buffering away results. The application will appear slugish. > The user would get bored. I can point you to dozens of studies > which show the correlation between response time and > productivity where humans are concerned. > 2) Often users will find what they want in the first 50 > results. This means you would have wasted a lot of time > brinigng back data you dont need. However they wont always find > what they want in the first 50. So the option for more must be > there. So why not use "web" like paging I hear you say. Well > because the query is heavy. To re-run it each with a different > limit and offset still requires re-running it. One of the > solutions (there are many none ideal) is to have a growing > scroll bar. Ie it grows each time you fetch a batch of results. > But this like most of the solutions looks a little tardy to > a user (me being one of them). Perosnally I hate it when > a scroll bar keeps growing when you reach the bottom. > > The few other approaches have been mentioned in the previos > post to this thread. > > Your extremly simplistic view on this is a result of never > dealing in volumous data and result sets and quick running > queries. Once you put volumes into your thinking cap you will > begin to see why you dont just read everything into memory for > the hell of it. > > Think about it.
Thanks for your vote of confidence in my intelligence. Clearly, you are smart enough to figure out a solution without assistance. Nevermind, -- Aristotle Pagaltzis // <http://plasmasturm.org/> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
