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

[Sho Fukamachi]

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.

In other words you cannot do anything like this:



or











Sho



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

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 following. 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 Sun, Jul 20, 2008 at 9:10 AM, Sho Fukamachi <[EMAIL PROTECTED] > wrote:

what I'm missing...

Sho

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

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.

smime.p7s
Description: S/MIME cryptographic signature