couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Wall" <jw...@google.com>
Subject Re: Associating users and comments
Date Thu, 02 Oct 2008 14:43:50 GMT
This is definitely a different way of thinking and a few examples would
probably help the light bulb go off.

However I think if you look at the documentation and play with views and
sorting a little you'll have everything you need.

On Wed, Oct 1, 2008 at 11:07 PM, Ben Bangert <ben@groovie.org> wrote:

> On Oct 1, 2008, at 8:42 PM, Paul Davis wrote:
>
>  I think what you're running into is the CouchDB != SQL impedance
>> mismatch. Its not overt and I see you're thinking about this, but I
>> still manage to not see my RDBMS prejudices after working on this for
>> a couple months.
>>
>
> I'm not a total virgin to non-RDBMS thinking, as I've used XML db's rather
> heavily, along with Google Datastore.
>
> So in an XML db, or even Google Datastore, I'd store all the comments for a
> post inside the post itself. No worries about conflicts because I can issue
> multiple updates to the XML document to insert additional comment nodes. As
> Chris Lenz mentions on his blog about CouchDB, under heavy load you need to
> keep comments out of the posts due to conflicts when updating the document
> and sending the update back to the db. So CouchDB is requiring a level of
> normalization that other document oriented databases do not (since they can
> update parts of a document without replacing the entire thing).
>
> As I'm forced to normalize to an extent in CouchDB due to its inability to
> update individual keys of a document without replacing the entire thing, it
> seems odd that its so dang hard to get some data together in a single query.
> It seems like CouchDB should either grow some scheme to let me get more data
> from separate related docs in one go, or it should allow for atomic updates
> of individual parts (or insertions of new keys) on a document without
> affecting the entire document (and thus causing conflicts and the additional
> normalization the inability caused).
>
>  I see that Chris managed to provide a reduce for the first question
>> which is good. The second answer is missing part of the question. As
>> in I think Ben was asking "Give me a list of users and their top 5
>> posts" which != "Give me user and top 5 posts".
>>
>
> Yes, if I wanted to list 20 users and their last 5 posts, that'd be 20
> run-abouts to the db. Granted the views are super fast, but the constant
> round-trip latency will add-up.


Or you can create a last 5 posts for users view. There is nothing wrong with
that. One important point of design for a database like CouchDB is that "one
size fits all views" are hard. The solution is to have lots of views. The
views are so versatile that you can do almost anything with them it just
takes a little more upfront work.

Alternatively, you can do the 20 roundabouts but in parallel so the latency
hit is only the longest roundtrip. CouchDB shouldn't have any problem with a
lot of simultaneous reads at once.


>
>  So far I think its clear we need better reduce docs. Also, I'm
>> thinking tomorrow might be a good day to start thinking about view
>> intersection/union syntax. Anyone that cares feel free to pipe up on
>> IRC or the ML. I don't see the implementation being difficult given a
>> decent method for specifying the sub queries.
>> This is definitely a different way of thinking and a few examples would
>> probably help the light bulb go off.
>>
>> However I think if you look at the documentation and play with views and
>> sorting a little you'll have everything you need.
>>
>> Maps collect all the data you want based on the criteria you want.
>> Reduce can rearrange collate and aggregate that data however you want.
>>
>> The various sorting and key restriction arguments can further restrict the
>> resultset. If I get some time I'll try to whip up an example for you later
>> today but I really think you've got enough information to infer it yourself
>> with a little experimentation.
>
>
>>
> Yes, that'd definitely help, and more examples of these common things to
> help others to get their head out of RDBMS-land. ;)
>
> Cheers,
> Ben

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