couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Wolff <>
Subject Re: How do you handle multiple document groups?
Date Thu, 05 Nov 2009 10:19:50 GMT
The multiple databases thing isn't a bad way to go. You can wire this
directly into your code that talks to couchdb via HTTP, since URLs are
predictable, so the app is like

couch.put("/foo/xyzzy", {...});

and the couch object in your app knows (via configuration or whatever) that
this should map to
this.put("/foo-1/xyzzy", {...});

We're doing something like this so that we can easily run integration tests
against test data

On Thu, Nov 5, 2009 at 2:02 AM, 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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message