couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: How do you handle multiple document groups?
Date Thu, 05 Nov 2009 11:03:55 GMT

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 "myapp.com" 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 foo.com and bar.com

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