On 23/07/2008, at 2:33 AM, Jan Lehnardt 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...
>
> Your gut feeling was correct, it is a bad idea.
Jan! I'd been hoping you'd comment.
Care to elaborate a bit? I would really appreciate your insight!
The simple situation is this: users can subscribe to other users. We
need to be able to query in both directions - ie, starting with a
known user, get the user records he is subscribed to - and the other
direction, starting with a user, get the user records of those
subscribed to him.
I had actually been bending to the "followers" table a little, after
doing some benchmarks and finding that 99% of the time just
individually GET-ing the list of users (in either direction) from a
list of IDs obtained from the followers table was going to be fast
enough.
I would *like* to place subscriptions in one or the other but just
cannot think of how it is possible to write the views *in both
directions* once it's stuck in a user, and I end up having to do the
GET loop anyway.
Would love to hear your views : ) Please let me know if I am not
making any sense.
Sho
PS sorry all those who are sick of this thread ....
> Cheers
> Jan
> --
|