Re: Modelling Question

[tsuraan <ts...@gmail.com>]

> 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 :)

Re: Modelling Question

[Ning Tan <ni...@gmail.com>]

On Thu, Oct 1, 2009 at 5:12 PM, tsuraan <ts...@gmail.com> wrote:
> 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?

Are mailboxes concrete documents or merely an abstraction (e.g.
supported by tagging the mail messages maybe)? I like the latter
better than the former.

I'm not sure you need the reduce part of the MapReduce framework here
if all you need is a list of messages. Be care generating a large
amount of data from your reduce function; it's not meant to support
that.