On 2011-10-24, at 11:26 PM, "Jim Giner" <jim.giner@xxxxxxxxxxxxxxxxxx> wrote: > Yes - but - we're talking about a user-app that the OP is trying to provide > 89M records to. Sure - "some" users might have need of looking at even as > much as a million records IF they were researching something that needed it. > But - for the 'general' user of an app - I cannot see a need to be providing > even that much data. Think about it - you give the user 1M records, how > long is that user going to page thru the results? Let's say there are 20 > results on a page and it takes a mere (wow!) 2 seconds to scan thru them > looking for something apparently very obvious. That's 600 results viewed > per minute at best. Six hundred into a M is 1666 minutes which is 27+ > hours. Even at 1 second per page view time, it's still more time than in a > normal work day. And you want come up with a way to feed him 89M? > > The problem needs to be looked at differently - put together a > business-smart solution to finding the needle in this haystack of 89M > pieces of straw and only then apply technology to it. > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > I agree, Jim. Which is why I was asking a about tuning the queries. Jason already indicated he was using limits and offsets, so it's other avenues i was looking for. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
