Its quiet simple: 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. On 10/25/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
I still fail to understand the problem. Either you want the data from the query, or you don't. If you want it, then you run the query once and buffer the results in memory before you process them, so you know the count before you start processing. Or you don't want the data, then you use a COUNT(*) query. In either case, it is only one query you need to run.
