On Fri, Jun 26, 2009 at 10:39:06AM +0800, hhsuper wrote:
> seem difficult to execute this logic in reduce, except i return a large
> object( which i don't like ) to make sure i can execute the same logic
> in re-reduce part, i can return the additional value which hold the
> {'dialogid':bestScore,....} in the reduce function and that could make
> sure i can execute the same logic in re-reduce part, but when user
> studied dialog more and more, the reduce value got lager and larger
> should i get a conclusion that logic like this isn't proper to
> implement in couchdb's view?
That's what I've been trying to say :-)
> also as you say i can download all data to client to caculate, but
> this is very costly and have scalable problem.
I don't think this is necessarily the case. Downloading 1,000 small
documents as a single JSON object in a single HTTP request is cheap. And as
for calculation, this is *better* done at the client, because it's easier to
scale with multiple clients on a single database, than multiple databases.
But if you don't think CouchDB is a good fit for your application - that is,
if you can find something more suitable - then I would advise you to use
that instead.
