couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Deibert <mark.deib...@gmail.com>
Subject Re: Design Question: What is a Good Model?
Date Wed, 09 Oct 2013 17:36:18 GMT
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.
>
>
> 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 <rangerrick@gmail.com> 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.
>>
>
>

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