On Wed, Apr 8, 2009 at 12:04 PM, Chris Kilmer <[email protected]> wrote: > I have some design questions. First about query design and then about > document design. > > 1. Query design: We have a set of existing documents, Project, User, > and Membership. Business constraints: A user is associated with many > projects through membership. A user can also be marked as a project > owner through the membership. A project can also retrieve a list of > it's owners. Given the constraints, some sample documents are: > > User > {'id' : 'xxx'} > {'id' : 'yyy'} > > Project > {'id' : 'aaa'} > {'id' : 'ccc'} > > Membership > {'user_id' : 'xxx', 'project' : 'aaa', 'is_owner' : true} > {'user_id' : 'yyy', 'project' : 'aaa', 'is_owner' : false} > {'user_id' : 'xxx', 'project' : 'bbb', 'is_owner' : true} > {'user_id' : 'xxx', 'project' : 'ccc', 'is_owner' : true} > > What I'm wondering, is: > > 1. What is the easiest way to retrieve all the projects where a user > is the(an) owner? (our current implementation uses two queries) > 2. What is the easiest way to retrieve all the owners for a particular > project? > > > On another front, I realize the way the documents above are laid out > is 'very relational'. I would love some ideas about on modeling the > relationships (should I even be using that word?) in a more document > centric manner. > > -- > Chris Kilmer >
Wow, totally wrote an entire email answering the wrong question. The way you've got this setup you're going to need at least two queries. I can say that the most efficient method would be to use the CouchDB joins pattern [1] to retrieve all project id's and then use a multi-get fetch to get each project's document. Also, I can't think of another way to do that in two queries so I'll assume that's what you're doing. XD The issue you want to think about when designing your document structure is that with the current Map/Reduce implementation that doesn't have chainable or joinable indexes is (for lack of better description) what I would call information hop. We'll define a single hop as looking at one document and following a reference to a different document to pick out some information. If you have a document structure that requires more than a single hop, you're going to need multiple queries. I've got some different ideas on things to implement that could help a lot in this area but I have to figure out how to implement those without destroying the current view engine and maintaining efficient view reads. I'm fairly certain its possible though... HTH, Paul Davis [1] http://www.cmlenz.net/archives/2007/10/couchdb-joins
