From: Isabelle M. <met...@pa...> - 2002-07-30 18:53:44
|
Hi everyone, I don't think chunking is a good idea, it doesn't scale well (as Amit = pointed out), plus the databases already do it. For example, if you send = a query for 10000 rows to Oracle, it sends it back in chunks of = something like 50 rows. The model underlying resultsets is that a cursor = is opened, and then there are repeated fetches until there is no more = data.=20 I'm also not clear on how you see the technical implementation of = chunking. Let's say the query is "select * from authors where first_name = like 'ISA%'. How are you going to tell the database to return only N rows? I don't = think you can. So the only thing you can do is sit there waiting for = data, collecting it until there are N items, and then pass them on to = the user. What have you gained in doing that? IMO : nothing. What might be useful, though, is the possibility to cache a resultset = (i.e. save it so that the query doesn't have to be executed next time = around). But : (1) a piggish user might use up all available memory for one gigantic = query, so you need to have policies in place for max space per = connection (2) you need a policy for invalidating stale data (that has been sitting = there for a long time without being requested) (3) you might to collect usage patterns for each cached resultset, and = adapt the cache to that pattern. For ex. if there are 10000 rows in the = cache, but in 100 requests nobody ever went beyond row 1000, you might = as well throw out the last 9000. Think searches on search engines : how = many times do you look at the 11th page? (4) you need a notion of "cache-ability". For example, there would be no = point in saving "select * from authors where first_name =3D 'Ronald" and = last_name =3D 'Reagan'. (too specific =3D=3D> likelihood of being = requested again too small) Isabelle |