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 19:12:08 GMT
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.


On Thu, Nov 5, 2009 at 3:03 AM, Jan Lehnardt <> 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 "" 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 and
> 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 <> wrote:
>>> 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.
>>> Cheers
>>> Jan
>>> --

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