couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sho Fukamachi <>
Subject Re: when to use another document and when not to?
Date Mon, 21 Jul 2008 02:25:54 GMT
Hm - I think I must have put myself badly before. I agree that there  
will obviously be less contention and overhead for single "membership  
table" style records storing this kind of thing. This kind of table is  
usually called a join table, and if we were talking about an SQL  
database I would agree this is the best way to do it.

But we are not talking about an SQL database. As far as I understand  
it there are limitations on what kind of query you can do with map and  
reduce, and one of those limitations is that you cannot join across  
tables the same way you can in SQL. Because of that, as I understand  
it, you cannot use a "followers" table to easily or cheaply get a list  
of users following a certain user, or a list of users that a  
particular user is following, or updates from the users someone is  

In other words you cannot do anything like this:

select users.* from users INNER JOIN followers ON  
followers.followed_user_id WHERE followers.following_user_id = ?


select updates.* from updates INNER JOIN followers ON  
updates.user_id=followers.followed_user_id WHERE  
followers.following_user_id = ?

As far as I understand it these kind of queries just don't exist in M/ 
R land, obviously people should know this before they make design  
decisions that rely on them. An obvious use case for this kind of  
database record is: starting with one user ID, select a list of users  
who are following that user. As I see it there is no efficient way to  
do this using a "followers" table in CouchDB; you could get an array  
of IDs in one query, but then would be stuck with an n+1 situation as  
you looked up each follower in turn. I would love to be proven wrong,  
of course...

I am not saying I wish CouchDB had this type of query, btw. I am  
saying that a "followers" table seems to me to be an RDBMS-specific  
design pattern and very likely is inappropriate for use with CouchDB.

Judging by the lack of controversy on this point it seems like  
everyone already knows this and has come up with alternative solutions  
- I guess I was trying to provoke some discussion on what those  
alternatives were ..

Or, obviously, I would be delighted if someone could show me how I'm  
completely wrong and it is actually possible to do this : )


On 21/07/2008, at 5:27 AM, Patrick Aljord wrote:

> On Sun, Jul 20, 2008 at 9:10 AM, Sho Fukamachi < 
> > wrote:
>> The outcome of the previous discussion on this thread seemed to be  
>> in favour
>> of the use of a "followers" table which I thought was a pretty bad  
>> idea in
>> CouchDB. I'd love to hear some defences of that, maybe someone can  
>> tell me
>> what I'm missing...
>> Sho
> As Damien said, if the user follow many people, its document could get
> huge and updating it would be expensive cause in couchdb you cannot
> query or update one "row" only, you need to get and put the whole doc.
> So if a user following tons of people updates often that wouldn't
> scale very well.

View raw message