Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
User-Agent: Kaiten Mail
In-Reply-To: <AF4EF1B0-3B6A-48E1-A0F7-B38B5046498B@programmazione.it>
References: 
 <CA+hbwtfnxfE4pwCGeF4CAnq6Yq9XdAHJnkLGRPN34wRE4H_J7A@mail.gmail.com>
 <c5b38a08-151b-4fb9-b310-0e75fa6a8e84@email.android.com>
 <CAMGHjATZn-stSxrfLFJLDirKxoh8AE8seRW_XBN2a94Joq-xng@mail.gmail.com>
 <CAMGHjAQj2NtVXq3yh1QzADF+jCzYJYj-jMOn9S+fg=JtiGuwPA@mail.gmail.com>
 <AF4EF1B0-3B6A-48E1-A0F7-B38B5046498B@programmazione.it>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: Design Question: What is a Good Model?
From: "Florian Westreicher Bakk.techn." <stuff@meredrica.org>
Date: Wed, 09 Oct 2013 23:23:49 +0200
To: user@couchdb.apache.org
Message-ID: <c2a4b004-2814-484f-8c5c-a7cd4016b096@email.android.com>

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.