From user-return-3394-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon Feb 09 12:50:02 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 52058 invoked from network); 9 Feb 2009 12:50:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2009 12:50:02 -0000 Received: (qmail 96630 invoked by uid 500); 9 Feb 2009 12:49:56 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 96586 invoked by uid 500); 9 Feb 2009 12:49:56 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 96575 invoked by uid 99); 9 Feb 2009 12:49:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 04:49:56 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lady.donut@gmail.com designates 72.14.204.237 as permitted sender) Received: from [72.14.204.237] (HELO qb-out-0506.google.com) (72.14.204.237) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 12:49:49 +0000 Received: by qb-out-0506.google.com with SMTP id d11so1169626qbd.3 for ; Mon, 09 Feb 2009 04:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=KfO7u4fU2WuLjoTXne3EEfcEFHcuCqyGSoEiC2ITrlI=; b=MtzelpiD1QYFdVEgLSflFLu7Zsc1HLIbmxoMMpKMbm2wWy7EXEdHAkxOKqvYA2B1qJ 52xF1ovXCula/2UBVVDaiGbDUn8KD9ASys8EayPz2Ih7qKN7NTKS0UNAxH5rO3zG1CNv dZqv+lor8wkC+3PaJvjvOonGwMO2p1MTD74HQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=uZphh0sJwB+NSTysTvUSjWhSaKl3nBI1LDJYCG9YGfdWoCuukOq8JBZUtMT85+fIpZ WtfWzNN8sf8n4CXho7zqxqcOjooQ+g/MFQoBu9pZwiivOX3MhRDH1PX+ZDe7Tu01vD6w 0jaOjb83xWysLhfNbVR8hoHVe6c9TYApyAOZs= MIME-Version: 1.0 Received: by 10.65.121.14 with SMTP id y14mr2566962qbm.37.1234183766904; Mon, 09 Feb 2009 04:49:26 -0800 (PST) In-Reply-To: <5186956f0902090338i2829df1erebaa24a4feea7e06@mail.gmail.com> References: <5186956f0902082052m43546a8dmb6d9a3ebf9685034@mail.gmail.com> <5186956f0902090228p5a6db266l764fde4c82b571d0@mail.gmail.com> <5186956f0902090338i2829df1erebaa24a4feea7e06@mail.gmail.com> Date: Mon, 9 Feb 2009 21:49:26 +0900 Message-ID: <5186956f0902090449s76befd76g4cf9ded9f59efc86@mail.gmail.com> Subject: Re: The Blog From: Mister Donut To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org I'll jump right in. > CouchDB won't allow you to "jump to page X", but if you look at > e.g. Google, it doesn't work either. [...] > But surrogate keys are considered harmful and I'd say (but that > really depends on the application), not very helpful. I guess I was assuming that CouchDB, due to its different nature, has a sophisticated solution for this. But apparently pagination is a problem that is really hard to solve. > Can you elaborate on that? I don't quote get the "or duplicate data, > basically anything that needs to be the same as something else" bit. Well. Let's say you have a list of documents. You want to store some information about the newest document in a separate key (instead of a view, which might be slow? if you have too many). That isn't possible. Or let's say you have documents, and categories. And many, many, many of them. Again, the view to show the latest document might be too slow, so you want to save that information in a separate key. Not possible. > A couple of things you can do with CouchDB replication (again, not saying, > that you can't do some of those with an RDBMS but it is getting harder > the further you move down the list): [...] Thank you for that list. I think, and like many other users, considering what I have read in blogs, seem to expect something else from CouchDB. I am not so sure where this is coming from. Check the Ruby thing a few mails down. How exactly is that implementation going to work without immediate consistency? Everyone seems to be going on about it being schema free, but you can just add a "param" field to any database and transparently (un)serialize and there you have it, schema-free. If you actually have a few nodes (with that implementation), it will break big, big time. I think, possibly, with the "Cloud Hype", that I got into believing, that it will "just work". With anything that you throw at it. Like what Amazon SimpleDB tells you it would. Yes, Key/Value pairs are incredibly easy. MapReduce is amazing and intriguing. But handling the replication, won't it be so difficult that you end up with a Quasi-Mini-RDBMS anyway? Now I got far away from my original questions, but I guess that happens often in discussions. Basically, now: "Is it possible to handle the replication in such a way that you don't end up with a Mini-RDBMS anyway in the end?" I would just, really really really, like to see an example that goes beyond schema-free. That handles replication. I think that would show where CouchDB shines, and where you'd fail with a RDBMS. And, CouchDB isn't magical glue to make pagination work, either.