From couchdb-user-return-1437-apmail-incubator-couchdb-user-archive=incubator.apache.org@incubator.apache.org Fri Oct 03 20:27:01 2008
Return-Path:
Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org
Received: (qmail 20136 invoked from network); 3 Oct 2008 20:27:01 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 3 Oct 2008 20:27:01 -0000
Received: (qmail 75216 invoked by uid 500); 3 Oct 2008 20:26:58 -0000
Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org
Received: (qmail 75182 invoked by uid 500); 3 Oct 2008 20:26:58 -0000
Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: couchdb-user@incubator.apache.org
Delivered-To: mailing list couchdb-user@incubator.apache.org
Received: (qmail 75171 invoked by uid 99); 3 Oct 2008 20:26:58 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Oct 2008 13:26:58 -0700
X-ASF-Spam-Status: No, hits=2.6 required=10.0
tests=DATE_IN_PAST_03_06,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [83.97.50.139] (HELO jan.prima.de) (83.97.50.139)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Oct 2008 20:25:55 +0000
Received: from [172.26.27.1] (tmo-096-2.customers.d1-online.com [::ffff:80.187.96.2])
(AUTH: LOGIN jan, TLS: TLSv1/SSLv3,128bits,AES128-SHA)
by jan.prima.de with esmtp; Fri, 03 Oct 2008 20:14:26 +0000
Message-Id:
From: Jan Lehnardt
To:
"couchdb-user@incubator.apache.org"
In-Reply-To: <2C17E6E1-5B77-40DA-800A-74A7E374D673@groovie.org>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (iPhone Mail 5F136)
Subject: Re: Associating users and comments
Date: Fri, 3 Oct 2008 17:04:29 +0100
References: <2098F155-ECB7-468E-8CA7-8E54F18EE606@groovie.org> <5152C024-ACC0-4FF7-AB45-171C0B2311EC@groovie.org> <16E99800-645D-4009-B499-7C94D71A4D92@groovie.org> <2C17E6E1-5B77-40DA-800A-74A7E374D673@groovie.org>
X-Mailer: iPhone Mail (5F136)
X-Virus-Checked: Checked by ClamAV on apache.org
On 02.10.2008, at 05:07, Ben Bangert 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).
Just a thought, I'm not saying CouchDB can't be improved: If you want
to change the core semantics of a given yechnology to "make it work"
for you it might be not the right tool for the job.
Cheers
Jan
--
>
>
>> 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