couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sho Fukamachi <sho.fukama...@gmail.com>
Subject Re: when to use another document and when not to?
Date Sun, 20 Jul 2008 11:13:53 GMT
If I can be permitted to drag this thread back up, I've been playing  
around with users and memberships too and how to organise them in Couch.

If I can summarise the options - please feel free to correct me here!  
- :

1. Store the membership (or "followers" record) in a RDBMS-style join  
table

ie,

_id
_rev
following_user_id
followed_user_id

Pros:
- compatible with what we all know from RDBMS
- can set options on the follower membership easily (eg,  
email_on_update = 1, created_at = Time.now etc)
- independent records unlikely to be "bombed" (update/revision  
contention if lots of people do something at once)

Cons:
- Cannot (currently) do a JOIN - equivalent using couchdb views. In  
other words, you can't start with one user and get a list of all users  
following him in a single query. The most you can get is their IDs by  
doing a view mapping the followed user's ID in the followers  
collection and outputting the following user IDs, which will have to  
be looked up individually (can't (yet) do bulk queries on a list of  
IDs either) - ie single query for the list of following user IDs then  
an n+1 query to get them all (eg their names)
- possibility of orphans in both directions (ie, either the follower  
or the followed might be gone) - requires application logic to detect/ 
fix

Pretty big problems with that one.

2. Store the membership in the followed object (in an array)

Pros:
- should, i think. be possible to get all the user records in one  
query doing something like user.members[i] = doc.id
- a certain concinnity in storing a user's followers in the user, i  
think
- memberships get deleted with the user, so no orphans in that direction

Cons:
- might cause contention if someone becomes suddenly popular
- becomes difficult to set options (the aforementioned email_on_update)
- possibility of orphans in the other direction - users gone but  
memberships still exist in the followed user

3. Store the membership in the following user

Pros:
- becomes super-easy to retrieve the list of followers of a user -  
just get everyone with their id in their "following" array
- much less likelihood of update contention since users are only  
updating themselves when they follow someone
- seems good that a user's action (to follow someone) affects only  
"their" record

Cons:
- becomes difficult to get a list of followed users starting with the  
following user


Also this one has the equivalent "orphans" pros/cons as 2, reversed.

So which is best? For now, I am leaning towards 3, but I'm going on  
gut feeling mainly.

I would really appreciate other's insights on this subject. The  
previous discussion doesn't seem to be aware of the absence of sql- 
style JOIN (across a memberships table) so I'm really interested on  
what others think about this.

Of course, someone telling me it is actually possible to do a 3-way  
join (user -> followers -> users) in couchdb would be aweomse, though  
unexpected : )

thanks

Sho



On 15/07/2008, at 9:54 AM, Patrick Aljord wrote:

> Thanks all for your answers.
>
>> Keeping a document that contains a list of users subscriptions  
>> seems better
>> than a document containing all of a user's followers, particularly  
>> with the
>> end-user update models. However, I'd think either list can get  
>> large, which
>> is expensive when that document is updated. If users have lots of  
>> things
>> they follow, and that list is updated frequently, then it's still  
>> expensive.
>> I'd consider creating a separate document for each "subscription",  
>> a mapping
>> of a user following another user.
>>
>
> Indeed, the list of followers can get relatively big especially if the
> user could follow things other than users such as groups, forums,
> posts, projects etc so the user doc could get pretty big and even if
> the user doesn't update very often the list of stuff he/she follows,
> it would be expensive to do so when it happens.


Mime
View raw message