couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tsuraan <tsur...@gmail.com>
Subject Re: Modelling Question
Date Thu, 01 Oct 2009 21:12:15 GMT
> 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 :)

Mime
View raw message