I was just thinking more about your "models" question. If this were me, I'd
skip the "Favorites" linking table all together. Add a "Favorites"
attribute to the "User" doc. In this Favorites attribute, put an array of
Event UUIDs. That flattens things out more and greatly simplifies your
views and queries.
On Wed, Oct 9, 2013 at 1:36 PM, Mark Deibert wrote:
> To follow on: sounds like you need 3 docs "events", "favorites" and
> "users" or just use the built in "_users" which may be better. Do your best
> to keep your docs denormalized as much as possible/sensible. Also keep
> something in mind, with no-sql dbs, you will frequently have to query
> multiple views in a sequence to effect relationships/joins. And definitely
> lookup views with compound keys. This is how you will "join".
>
>
> On Wed, Oct 9, 2013 at 1:23 PM, Mark Deibert wrote:
>
>> The reduce function is for aggregating data in a view. You'll need a view
>> with a compound key to "join" two types of documents. Lookup compound keys
>> in views. I'll post again later if you need more help.
>>
>>
>> On Tue, Oct 8, 2013 at 4:31 PM, Florian Westreicher Bakk.techn. <
>> stuff@meredrica.org> wrote:
>>
>>> I'm also new but I would just use a view for that. You can emit user
>>> names as key and favorites as values and later query it with key=username
>>>
>>> function map(doc) {
>>> if(doc.type === 'favorite') {
>>> emit(doc.user, doc.favorite_id);
>>> }
>>> }
>>>
>>> Cheers,
>>> Florian
>>>
>>> (coding on mobile is hard)
>>>
>>> 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?
>>>
>>> --
>>> Sent from Kaiten Mail. Please excuse my brevity.
>>>
>>
>>
>