couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florian Westreicher Bakk.techn." <st...@meredrica.org>
Subject Re: Design Question: What is a Good Model?
Date Wed, 09 Oct 2013 21:23:49 GMT
Quick question: why would a complex key be required? Could we not emit (userid, eventid) and
be happy? 

Filippo Fadda <filippo.fadda@programmazione.it> wrote:
>Mark is right, you need 3 different document types. The Favorite
>structure will have: _id, _rev, userId, eventId, timestamp (it's always
>a good idea to store the timestamp because you might use to sort data
>eventually).
>
>If you have a list of events and you want show a 'star' on every event
>starred by the current user, you have to make a query (one for each
>event unfortunately) using a complex key [eventId, userId]. 
>
>This is the best approach to avoid conflicts, because your events and
>your users will never change when a new event has been added to the
>user favorites.
>
>Bye
>
>-Filippo
>
>On Oct 9, 2013, at 7: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 <mark.deibert@gmail.com>
>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.

-- 
Sent from Kaiten Mail. Please excuse my brevity.

Mime
View raw message