couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <jch...@grabb.it>
Subject Re: when to use another document and when not to?
Date Mon, 14 Jul 2008 23:19:28 GMT
On Mon, Jul 14, 2008 at 4:04 PM, Dean Landolt <dean@deanlandolt.com> 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. 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. If it were something
> more akin to logging information, it probably belongs in its own doc just
> due to versioning overhead that would be created by creating a whole new doc
> for every new write...

I'd agree with your recommendation - having the information together
in 1 doc will make it easier to generate the views you'll want to use,
and updating the user's doc is a relatively low-contention activity.

I split data into multiple docs in cases where I don't want to have to
load the original doc to make changes and then re-save it.

In your case, you won't be adding to a user's friends unless the user
is around (as in visiting your website) so you've probably already
loaded the user's doc up. Also, a user probably isn't making
concurrent write-requests to different replicas of your data, so
saving changes to user docs shouldn't result in conflicts very
frequently.

In the case of logging or metrics application, you probably want to
split docs so that you never end up changing them, because doing the
GET / PUT loop for every additional chunk of information will add a
lot of overhead. Also, building views from the small atomic data
chunks probably makes the most sense.


-- 
Chris Anderson
http://jchris.mfdz.com

Mime
View raw message