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
following.
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 = ?
or
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 : )
Sho
On 21/07/2008, at 5:27 AM, Patrick Aljord wrote:
> On Sun, Jul 20, 2008 at 9:10 AM, Sho Fukamachi <sho.fukamachi@gmail.com
> > 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.
|