On 02.10.2008, at 05:07, Ben Bangert <[EMAIL PROTECTED]> 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
