Le 21/04/2011 11:23, Ryan Ramage a écrit :
>>> You might want some architecture like this:
>>>
>>> [] Public Docs db |
>>> | <----- hosted
>>> [] User 1db [] User 2 db [].... |
>>> ------------------------------------------------------
>>>
>>> [] User1 phone db [] User 2 Phonedb []....
>>>
>>> Then have replication between phone and user db. Then have replication
>>> from Userdb to public docs db with a filter to take out private
>>> tags...
>>>
>
>> Hum, something like that could yes. But I have a question regarding the
>> stats. First, a tag can only take a value in a predefined set of value
>> for that tag. So, is it possible that instead of filtering the tag
>> completely, I update the stat of the value accordingly (+1 if the value
>> has been chosen by the user, -1 if the user changed to another value or
>> reset the tag)?
> CouchDB filtering is currently a yes/no operation per doc. So you
> would want to have related docs to the tag that hold the 'stat of the
> value'. Filter the parent tag doc, and let the 'stat of the value'
> docs go back to the public db.
>
Ok, that could work then.
>> Oh, and also, I read that there is a limit depending on the OS for the
>> number of concurrent databases. Won't that be a problem if there is a
>> lot of users (which will hopefully be the case;)?
> Yes, there will be a limit on how many for concurrent dbs per OS. It
> is really high anyway. Someone else will have to give real life
> numbers on this. But if you hit the wall, just add more servers. They
> are cheap as chips :) The couch replication model is nice because it
> is flexible with how you might grow.
>
All right, well, thanks for everything, I'll see if I can convince my
boss now ;)
> Ryan
