Sho, Don't apologize it's better for everyone using couch to get these out in the open so that as the community grows there's an idea of expectation and how to work through these problems. I think it's great to have a thread like this for people to use as a resource. Especially now that we have benchmarks.
Brad ----- Original Message ---- From: Sho Fukamachi <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, July 22, 2008 12:19:35 PM Subject: Re: when to use another document and when not to? 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 > --
