CouchDB will compute reduced values for what you select. If you just
ask for values from A to B, it *only* will compute the reduced values
over that range. So you can get "clever" with the key value, using
something like
map: emit( [user,game,trynumber], score);
where trynumber is some value that is guaranteed to increase with each
completed game score stored.
Your reduce could use the built-in Erlang _sum
Then you can just request something like...hmm
startKey=[user,game,BIGNUMBER]&order=descending&limit=10&reduce=false
(where BIGNUMBER is something bigger than the highest try number of game).
This will give 10 values, and you can do the average lickety-split
client side, OR you can do one query to get highest try number, then
another to get between that game and ten back to let couch compute the
sum for you.
I'd play around with that kind of an approach, but I would recommend
*against* computing the mean in the reduce, although you could do it.
It is much slower than using _count or _sum. Using my approach, Couch
will get the sum value, not the average, but you also should know the
rows and so can compute the simple arithmetic mean much faster than
serializing the data back and forth from JSON on the server.
As an aside, invariably I've found that when I use arrays for keys I
generally run into at least one case where I want to shuffle the order
of the keys and therefore generate an almost identical copy of the
view's data just to get a different organization of the tree.
Hope that helps,
James
On Sun, Apr 15, 2012 at 02:02:21AM +0300, Alon Keren wrote:
> Hi,
>
> I have the following scenario:
> a player can play one of many types of games. After finishing a game, the
> player's score is kept in a new document.
> I'd like to list a player's average score in the latest 10 games, for all
> types of games.
>
> I don't see an easy way to solve this with CouchDB, unless there was a
> feature that limited (group-)reduce operations to just the first 10 of all
> possible rows.
>
> Has anyone else encountered a similar situation? Would this feature be
> useful to others? If so, would it be technically feasible to implement?
>
> Thanks,
>
> Alon