incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Campbell <rrc...@gmail.com>
Subject Re: How do you handle multiple document groups?
Date Thu, 05 Nov 2009 10:47:18 GMT
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.


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

Mime
View raw message