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 Fri, 06 Nov 2009 08:43:42 GMT

On 5 Nov 2009, at 20:12, Adam Wolff wrote:

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

I'm not sure how "typed databases" have any impact on scaling. I like  
self-self contained databases because they are easier to reason about  
and easier to handle practically (delete a user / delete the db,  
done). Not that it is generally a bad thing but "typed databases"  
smell like RDBMS tables to me. There might be nothing wrong with it in  
certain applications, in others, it might lead to wrong design choices.

Cheers
Jan
--


>
> A
>
> On Thu, Nov 5, 2009 at 3:03 AM, Jan Lehnardt <jan@apache.org> 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 "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