couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: How do you handle multiple document groups?
Date Thu, 05 Nov 2009 10:19:45 GMT

On 5 Nov 2009, at 11:02, Robert Campbell wrote:

> First, let me say that I posted this question to StackOverflow here:
> 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 "",
> "", "", "", 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.


View raw message