Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of ryan.ramage@gmail.com
 designates 74.125.82.54 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=GXthZQBQ7CNM0lvWH8Fs0cpV5lrDWyDb+NLha+wyHqwsp/YuU+hyxszKW9NuMRi/cV
         xs7gkojzedruyVi5zzFlFl2L/tzhl4dykKCon+WtHEfEWyEdURN/cQwDdSlcO7lcr6EQ
         ph47S8zhJqLkFLnIVb70sCHQGVXOwfHPctX7Q=
MIME-Version: 1.0
In-Reply-To: <4DB06C48.3010306@gmail.com>
References: <4DAF1BE0.5070104@gmail.com>
	<BANLkTimuEakQG61CnN6fUYD=ksVYCO1BDA@mail.gmail.com>
	<4DB06C48.3010306@gmail.com>
Date: Thu, 21 Apr 2011 12:23:50 -0600
Message-ID: <BANLkTimVFiP+W0mFziTDibXM10j6ivuvBg@mail.gmail.com>
Subject: Re: Help needed: is couchDB a good fit for my app?
From: Ryan Ramage <ryan.ramage@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>> You might want some architecture like this:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [] Public Docs db =A0 =A0 =A0 =A0 =
=A0 |
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0<----- hosted
>> [] User 1db =A0 =A0[] User 2 db =A0[].... =A0 =A0 =A0 =A0 |
>> ------------------------------------------------------
>>
>> [] User1 phone db =A0 [] User 2 Phonedb =A0 []....
>>
>> 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.

>
> 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.

Ryan