Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of awolff@gmail.com designates
 209.85.216.201 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;
        b=P/FuzuDt1DQVEFPZHO08hKc1WsgNVvyZy1zSEFvck1zJbf/M7nADEo+y0SsbE34TIa
         UeQC2W1FwzNh/IMrDOgG+A8cqxW9en/Uw+WApZupJr9FK78JvG613kw+3msHmUywfwGF
         NH5XK2yUsEYOsIsE2fFpevkrEQGmbTaMC9R3Q=
MIME-Version: 1.0
In-Reply-To: <CC9DFE9A-209A-4E86-A3B1-97B25F56A7BC@apache.org>
References: <b57c4e1c0911050202n1a585b70m16fbf7776ec05de@mail.gmail.com>
	 <5324CCF9-9806-482B-B30C-B07F1340F077@apache.org>
	 <b57c4e1c0911050247j27f8315aq1952c57344cbfd07@mail.gmail.com>
	 <CC9DFE9A-209A-4E86-A3B1-97B25F56A7BC@apache.org>
Date: Thu, 5 Nov 2009 11:12:08 -0800
Message-ID: <e8d26ac40911051112w28c54c66j205a8d29638955a5@mail.gmail.com>
Subject: Re: How do you handle multiple document groups?
From: Adam Wolff <awolff@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=000e0cd21222f91c150477a48094

--000e0cd21222f91c150477a48094
Content-Type: text/plain; charset=ISO-8859-1

Can I ask what the advantage of this is? Is this for replication? I like
having typed databases; it seems like that will be an easy way to solve
scaling problems.

A

On Thu, Nov 5, 2009 at 3:03 AM, Jan Lehnardt <jan@apache.org> wrote:

>
> On 5 Nov 2009, at 11:47, Robert Campbell wrote:
>
>  Okay, I _do_ like that CouchDB lets me use "/" in a database name, so
>> I can hopefully do "http://xxx/myapp_com/users" which feels better
>> thanks to the / delimiter.
>>
>> For something like "myapp.com" domain and "users" database. I'll just
>> have to replace all periods with underscores or something.
>>
>
> I wouldn't create databases per type.
>
> say user a has the domains foo.com and bar.com
>
> for that user the databases /a/foo_com/ and /a/bar_com
> are created. In these databases, all documents for the
> respective domain live. If you need additional info for
> the user that owns the domain that is not specific to
> the domain, I'd go with putting all user-specific info
> in each of the user's databases. This is duplication,
> but it doesn't really hurt, except maybe for users
> with hundreds and thousands of domains. In which
> case he/she probably pays you enough money to
> solve it :)
>
> Cheers
> Jan
> --
>
>
>
>
>>
>> On Thu, Nov 5, 2009 at 11:19 AM, Jan Lehnardt <jan@apache.org> wrote:
>>
>>>
>>> On 5 Nov 2009, at 11:02, Robert Campbell wrote:
>>>
>>>  First, let me say that I posted this question to StackOverflow here:
>>>> http://stackoverflow.com/questions/1674662/nested-databases-in-couchdb
>>>>
>>>> Here is what I mean by multiple document groups:
>>>> Assume you are building a blog engine which services hundreds of
>>>> domains. Within each domain, you would have similar groups of
>>>> documents: users, posts, comments, etc. How would you structure this
>>>> in CouchDB?
>>>>
>>>> One way would be to create a User database which contains users from
>>>> all domains. The user documents would have a "domain" field which
>>>> denotes which domain this user is valid on. Likewise, you would have a
>>>> single Post database, with each post document having a domain field
>>>> and so on. I don't like this solution because 1) you will have lots of
>>>> data duplication, where every single document has to denote the domain
>>>> it's connected to. 2) It seems like it could be a security problem.
>>>> One vulnerability in your view functions could accidentally return one
>>>> domain's user set to another, etc. If we change the blog engine into
>>>> an enterprise document management/workflow engine, you could have
>>>> serious problems exposing one document to a competitor.
>>>>
>>>> Another way you could do it is by bringing the domain group up into
>>>> the database level. This means you'd have "MyApp.com-Users",
>>>> "MyApp.com-Posts", "MyApp.com-Comments", "AnotherApp.net-Users", etc.
>>>> This helps reduce the data duplication and maybe the security issue a
>>>> bit, because now your documents don't need to specify a "domain" field
>>>> everywhere. Your app would follow the simple naming convention to
>>>> select the proper database. The disadvantage of this is that it feels
>>>> like a hack. What I really want is a MyApp database which contains
>>>> User, Post, and Comment sub-databases (for example) which then contain
>>>> the documents for that top-level group (domain) and lower-level group
>>>> (posts).
>>>>
>>>> How do you guys address this problem?
>>>>
>>>
>>> Give each user/domain combo a separate database. Lot's of databases are
>>> no
>>> problem.
>>>
>>> Cheers
>>> Jan
>>> --
>>>
>>>
>>>
>>
>

--000e0cd21222f91c150477a48094--