But I wanted to ask it again, and this time in the forums so I can get both longer answers and also have this question stored in the forums so others may benefit from the answers
Sure!
user: { _id, name, other_private_info, projects[(<--array of pointers to projects)], friends[(<--array of pointers to users)] }
project: { _id, name, other_private_info_like_commit_logs, issues[(<--array of pointers to issues)] }
issues: { some_data, creator(<-- pointer to a user) }
This will work, but a better design is to take advantage of views and represent one-to-many relationships in a more relational manner. For example, instead of having a project contain an array of issues, have each issue contain the ID of its project. Then create a view that, for each issue, emits its project ID as the key. Now you can query for all the issues of a project by restricting the key range to just that project’s ID.
It gets trickier with many-to-many relations like user<->project. The relational approach would use a “join document” containing a user and project ID plus metadata; this might be too much overhead. The concern with the array approach is conflict handling: is it likely that the array could be modified incompatibly by two clients? If so, you’ll end up with a conflict that’s difficult to resolve.
1) I don't want every user to have access to all other users' data. And I don't want it to be an application logic thing
Yeah. See the email I posted about a half hour ago with more discussion of this. It’s a very common design pattern, and CouchDB doesn’t have a perfect solution for it yet. The best pattern for now seems to be a database per user, with middleware to replicate between them and a master db.
—Jens