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" <[email protected]> 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?
