incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron Jacobson <came...@datashovel.com>
Subject Re: Design Question: What is a Good Model?
Date Sat, 02 Nov 2013 21:29:54 GMT
On 10/08/2013 10:10 AM, Benjamin Reed wrote:
> I'm extremely new to CouchDB, and to NoSQL and map/reduce in general.  I
> was wondering, what is the best way to design what I'm trying to accomplish?
>
> I'm writing an app, which will have a collection of (calendar) events,
> created by users.  Users will be able to mark events created by other users
> as favorites.
>
> In a traditional database, I'd have at least 2 tables:
> - an event table, with a column representing the user that created the event
> - a "favorites" table, which maps a user to an event that he has favorited
> - optionally, a user table with info about the user, and a unique ID that
> can be used in lieu of username in the first 2 tables when making foreign
> references
>
> In the (web) app I'm writing, I've got the events in couchdb:
>
> [{
>    _id: whatever,
>    type: 'event',
>    summary: 'foo',
>    description: 'bar',
>    createdBy: 'RangerRick'
> }]
>
> But what is the best way to retrieve the "favorites" associated with a
> specific user?  Do I just make a doc with an ID set to
> "RangerRick-favorites" and retrieve it directly?  Do I just put individual
> username -> _id entries in for each favorite?
>
> I currently am doing the latter, which didn't seem like a big deal until I
> had to pull just the list of events that match the favorites, and can't
> figure out how to make a map/reduce that does it efficiently.
>
> Do I just map anything that's a type=favorite or type=event and then...
> reduce it somehow by putting them together?
>


I don't believe the following option will be directly relevant to this
project in particular, but when dealing with highly related data, where
entities may have hundreds or thousands of relationships to other
entities, I find it quite nice to rely on a separate "relationships"
*type*, and compose views off of that in order to be able to pull
relationships of a particular entity or set of entities.  I have a small
project (not worth promoting here) where I basically tested this concept
out.  With the right composition of your keys in your views you can get
a useful subset of relational functionality (think in terms of a Graph
Database) where you can compose a number of levels of granularity into
your queries to get as much or as little information about your entity
relationships as you want.

At a certain point, if relationships grow more horizontally than
vertically (ie. multiple joins are needed to extract the relationships
as opposed to individual entities having many types of relationships to
other entities) it likely can become important to weigh the option of
incorporating a relational database to handle certain functions of the
system.




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