couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Query design questions
Date Wed, 08 Apr 2009 16:50:04 GMT
On Wed, Apr 8, 2009 at 12:04 PM, Chris Kilmer
<> 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...

Paul Davis


View raw message