Re: when to use another document and when not to?

[Sho Fukamachi]

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.

ie,

_id
_rev
following_user_id
followed_user_id

Pros:
- compatible with what we all know from RDBMS


Cons:


Pretty big problems with that one.

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

Pros:

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


3. Store the membership in the following user

Pros:


Cons:



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







thanks

Sho



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

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 - 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) - 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 - 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 - possibility of orphans in the other direction - users gone but memberships still exist in the followed user - 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 - becomes difficult to get a list of followed users starting with the following user 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 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.

smime.p7s
Description: S/MIME cryptographic signature