From couchdb-user-return-1523-apmail-incubator-couchdb-user-archive=incubator.apache.org@incubator.apache.org Tue Oct 14 03:07:46 2008 Return-Path: Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org Received: (qmail 83797 invoked from network); 14 Oct 2008 03:07:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Oct 2008 03:07:45 -0000 Received: (qmail 48246 invoked by uid 500); 14 Oct 2008 03:07:45 -0000 Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org Received: (qmail 48211 invoked by uid 500); 14 Oct 2008 03:07:44 -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 48200 invoked by uid 99); 14 Oct 2008 03:07:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Oct 2008 20:07:44 -0700 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 jchris@gmail.com designates 64.233.182.186 as permitted sender) Received: from [64.233.182.186] (HELO nf-out-0910.google.com) (64.233.182.186) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Oct 2008 03:06:37 +0000 Received: by nf-out-0910.google.com with SMTP id c7so1173865nfi.40 for ; Mon, 13 Oct 2008 20:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=jYMksLMoTg9GdUssZtzkQ5Y/dtehwqEtv4a1USvYeV0=; b=f28WUpoZd57E2tZHEJTqKh3hg5qGxNVb8b/mcWGtkiJBtz5+TYki5WPlQf5rb5sKTQ kzHMEz6E9/5xB2bntDVj+aWXZyHdsUyV3chNLvePoc1LfViZ34d8ga81ktSgKSNqFJZP /CTaC6ePBnhYQa++lOTh4tzh7vdKDmMfOStdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=wesIe1MR2NnjejfxDSoLLzgMz2tg+g2kwxHSY34nSrJ8FNV3TuHDMwmsB0u+UwSduM OzwjALvCa/I1GkbAqrkiJXFukOuvvk47zt4heyrIAZHSWkzewHl2a0Zfb1xYFx8h0Mhw 2RptYUM0EVDaB4LByHJyGUXuBFsqnOjhhuvRQ= Received: by 10.210.129.19 with SMTP id b19mr6533855ebd.9.1223953616183; Mon, 13 Oct 2008 20:06:56 -0700 (PDT) Received: by 10.210.54.17 with HTTP; Mon, 13 Oct 2008 20:06:56 -0700 (PDT) Message-ID: Date: Mon, 13 Oct 2008 20:06:56 -0700 From: "Chris Anderson" Sender: jchris@gmail.com To: couchdb-user@incubator.apache.org Subject: Re: When to use CouchDB, when not to... In-Reply-To: <25A49021-0F4A-4B39-9C4A-FEFDC0B3738F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <521183240810111938s2d60320fo30e47cdf22acc7d4@mail.gmail.com> <521183240810121228u3eef309dw7e44141701401e4e@mail.gmail.com> <7E19FE01-58AF-40A6-A785-4A6E9F3E4D51@gmail.com> <27d8d0930810131608r52b5b1bobcd6f75259a867f0@mail.gmail.com> <10F0F911-0B13-4D4A-9566-62BA3E420F62@gmail.com> <25A49021-0F4A-4B39-9C4A-FEFDC0B3738F@gmail.com> X-Google-Sender-Auth: 0cc6785eddf2a682 X-Virus-Checked: Checked by ClamAV on apache.org >> The sort of architecture I've been contemplating is one where certain >> heavyweight entities in the application would be stored in CouchDB while >> other lighter weight/more relational entities would remain in the RDBMS. I like draw a distinction between documents that can be edited, and documents that are write-once. The second type is great for logging-style data collections (which lend themselves to MapReduce reports), while the first fits most handily with data collections that will be edited by the user. Unless you have data that really hits the RDBMS sweet-spot (social graph, maybe...) I'd make a go of designing a system that uses only CouchDB for persistence. I'm leaning this way, because I think there's a lot of space to be explored in terms of how to structure and maintain document based applications. I guess I think the overhead of keeping the two systems in sync might outweigh the benefits of "in the box" joins and such that you can get from a SQL overlay. If you do go with a mixed system, it would be interesting to hear how you handle any impedance mismatches that come up. Chris -- Chris Anderson http://jchris.mfdz.com