Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1076)
Subject: Re: How do you handle multiple document groups?
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <b57c4e1c0911050202n1a585b70m16fbf7776ec05de@mail.gmail.com>
Date: Thu, 5 Nov 2009 11:19:45 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <5324CCF9-9806-482B-B30C-B07F1340F077@apache.org>
References: <b57c4e1c0911050202n1a585b70m16fbf7776ec05de@mail.gmail.com>
To: user@couchdb.apache.org


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