On Jul 14, 2008, at 7:04 PM, Dean Landolt wrote:
I've been wrestling with this myself, and the only rule of thumb
that makes
any sense to me is just to spin off a new object if the new type of
data
tends to grow rather than change.
Good rule of thumb I think.
In the example you put forth, that seems
like the kind of data structure that is subject to change so it
seems like a
better candidate for nesting inside the parent doc.
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.
-Damien
Dean
On Mon, Jul 14, 2008 at 6:46 PM, Patrick Aljord <[EMAIL PROTECTED]>
wrote:
Hey all,
I'm playing with couchdb and I'm wondering when should I just use
another field in the doc or another doc.
Say, I have users, each user can follow many users. Should I put all
the followed users in a field of each user doc (as an array) or
should I create a Follower doc with the id of the followed user and
the id of the follower user.
What's the general "rule" if there is one to know when it's best to
use a separate doc and when not to?
Thanks in advance
Pat
