couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Hallett <halle...@gmail.com>
Subject Re: Modelling Question
Date Tue, 29 Sep 2009 15:56:51 GMT
I think the answer depends on what you want to do with this data.  The
information you provided is nicely detailed, but seems to me to come down to
a generic "how does one represent a many-to-many association in CouchDB?"

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.

Sofa, Chris Anderson's blogging app, demostrates this technique with
one-to-many associations.  But thanks to CouchDB's design features
many-to-many relations can be implemented in essentially the same way.

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.

On Sep 28, 2009 11:54 AM, "tsuraan" <tsuraan@gmail.com> wrote:

I guess this is a pretty generic NoSQL question, but I figured this
would be a reasonable list to ask it on.

I'm trying to figure out how to model a mailbox scenario with Couch.
The idea is that you have users, mailboxes, and mail sources.  A user
can have multiple mailboxes, and each mailbox is fed by a mail source.
 Each mail source feeds multiple mailboxes.  Users have control over
their mailboxes; they can create a mailbox associated with a single
mail source, and they can delete their mailboxes when they feel like
it.

In SQL, I'd have three main tables: Users, Mailboxes, MailSources.
Between Users and Mailboxes would be a mapping table, and between
MailBoxes and MailSources would be another mapping table.  When a user
deletes a mailbox, the relation between that mailbox and its source is
automatically cleaned up by the database's internal logic.  How can
that action be done in CouchDb?

How would a person model this entire thing in CouchDb?  Would you
basically have the same three tables for the data, the same two
mapping tables for user's mailboxes and mailboxes' subscriptions, and
have application-level logic to manage the cascading deletes, or is
there a better way?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message