couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Johnson" <arach...@notdot.net>
Subject Re: Associating users and comments
Date Thu, 02 Oct 2008 14:55:06 GMT
On Thu, Oct 2, 2008 at 5:07 AM, 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).


Actually, FWIW, the App Engine datastore acts much like CouchDB in that it
only supports writing entirely new copies of entities. If you used the
technique you describe, either you would have concurrency issues destroying
some of your comments, or you would have to use transactions to prevent it
from happening.


>
>
> 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.
>
>  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.
>>
>
> 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