From user-return-6653-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Oct 01 21:13:48 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 66109 invoked from network); 1 Oct 2009 21:13:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Oct 2009 21:13:47 -0000 Received: (qmail 18898 invoked by uid 500); 1 Oct 2009 21:13:46 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 18818 invoked by uid 500); 1 Oct 2009 21:13:46 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 18808 invoked by uid 99); 1 Oct 2009 21:13:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 21:13:46 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tsuraan@gmail.com designates 209.85.221.179 as permitted sender) Received: from [209.85.221.179] (HELO mail-qy0-f179.google.com) (209.85.221.179) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2009 21:13:37 +0000 Received: by qyk9 with SMTP id 9so732410qyk.30 for ; Thu, 01 Oct 2009 14:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=WW3GH6jfquJ2j7wEkxkO+RInmfYzM0C92VBBP5EmlbQ=; b=roTg60aEIVBEpG80LqMmZxcaE9hzUplN64M71ZabXNpoUWbB0O4l9VvnHNXqRd1uqy c+ZBiUGQyPzhQ1K7+dlwcelwlRjNXUkHKezKR9+mUle68q3ileuCDhcJiW1vt/JmZ+8E TJ8nIzf/yi1ozBrPleFwlOf+3HdChRZmuT1D0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=hx0MqJ8S2MhkaxFN7B+aHUuFLaYS+RVLx3caiJrX0yYsG0g6f8I5Gd/QmVo5lGqnm7 DInCl5Cop/NSc6BThIkKv89eFI+2U79+LdQFRY6hl8lQgXEyhGyDb/5yOSEntXMk2dQl Ud0YxDPGNEXljItiZqGIWRce8ZdIzBuXmh4e0= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr2266549qcd.15.1254431536059; Thu, 01 Oct 2009 14:12:16 -0700 (PDT) In-Reply-To: <8a02878f0909290856i31eec803lf80650f602397105@mail.gmail.com> References: <84fb38e30909281153q5cc93c01od2b2692bf5501d6a@mail.gmail.com> <8a02878f0909290846o18be76adxeb42bf1ed941fab@mail.gmail.com> <8a02878f0909290856i31eec803lf80650f602397105@mail.gmail.com> Date: Thu, 1 Oct 2009 16:12:15 -0500 Message-ID: <84fb38e30910011412n14a23f13p9e087cfb6ac981ee@mail.gmail.com> Subject: Re: Modelling Question From: tsuraan To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org > One simple way is to store association links in one of the main documents > instead of on a separate table. Pick one side, for example mailboxes, and > store the ids of each mail source that a box is connected to in the mailbox > document itself. Using CouchDB's mapreduce views you can emit a separate > view row for each pairwise link, retrieve all of the mailboxes connected to > a mail source in a single query, and so on. Ok, so in my case, a user needs to be able to edit his mailbox (delete messages from it, mostly), so each user needs his own mailbox. If the structure of the user table is something like: { "username" : name, "mailboxes" : [ { "entries" : [ list of messages ], "source" : name of email source, "name" : whatever the user wants to call the mailbox }, ... ]} Then email delivery for each email creator would be a map-reduce job that delivers email into every box whose source entry matches the name of the email creator. Does that make sense for Couch? Is that something that is reasonable to do in a map-reduce job, and would it perform reasonably? > Strategies will differ with other postrelational databases since they are > all so different. I'm afraid there are not a lot of generic NoSQL questions > - they usually have to be tailored to a specific database system. Yeah, that makes sense; couchdb and tokyo, for example, are certainly going to have different solutions to the same problems :)