From user-return-8176-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Tue Dec 29 06:10:26 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 75042 invoked from network); 29 Dec 2009 06:10:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Dec 2009 06:10:26 -0000 Received: (qmail 71666 invoked by uid 500); 29 Dec 2009 06:10:24 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 71482 invoked by uid 500); 29 Dec 2009 06:10:24 -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 71472 invoked by uid 99); 29 Dec 2009 06:10:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Dec 2009 06:10:23 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of seanhess@gmail.com designates 209.85.216.187 as permitted sender) Received: from [209.85.216.187] (HELO mail-px0-f187.google.com) (209.85.216.187) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Dec 2009 06:10:16 +0000 Received: by pxi17 with SMTP id 17so24339167pxi.30 for ; Mon, 28 Dec 2009 22:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=zTt8O6U73b9xEE0pWj1k0X4L4RgzkPtasJU8HXFxaHU=; b=aYdQ/7tKCgeC067TJcyF0ohOiMnZcN+hyMiy9gFSiIgHhcWjrsyq9TEVrS/KzTpXVg HHbcVOH2NGt0KgNFQYxRFlJtXr6WmXNJYTJ/vqAv6+T0xLh3VC5ZxajIRutwsKbjjpVZ 12LWGAXCnaTu/B7KAHOUTYIunFTo00ku/wbGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JpPqdu9/LzMDnTpJi6J1Mx58tv2Xa2I5wNNGvNa0h+8SXj0tiXPRqqSNnEKLXnKTg1 9hTaYgYDHTVfGKIlrKz62IreiBJ0Dt/MFYhnQkjzXp8qX6aTkBTEi7o8ou4i/mCweEXJ BZuuDEughMIaqThIgl71+99y8uw4nAwA0pv58= MIME-Version: 1.0 Received: by 10.141.188.21 with SMTP id q21mr11816484rvp.148.1262066995398; Mon, 28 Dec 2009 22:09:55 -0800 (PST) Date: Mon, 28 Dec 2009 23:09:55 -0700 Message-ID: <21a5a18d0912282209ic072c3flbef36c821347ea37@mail.gmail.com> Subject: Designing a database From: Sean Clark Hess To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=000e0cd17c98f189d2047bd7de2a --000e0cd17c98f189d2047bd7de2a Content-Type: text/plain; charset=ISO-8859-1 Our system will have comments related to live data - imagine people commenting on tweets right after they are written. I'm having trouble deciding how to model it. It makes a lot of sense to make one document containing all the comments for each data segment, but we could theoretically have hundreds of users commenting on the same segment at once. Would data consistency become a nightmare? With an RDBMS you would have a comments table, and insert a new row for each comment - preventing conflicts. I could do the same thing with couch, by adding a separate document for each comment, but it seems to violate a fundamental principle of couch. Is Couch DB a bad fit for an update-heavy system? Updates will only be heavy within the first minute or so after the data is released, then it will switch to a very read-heavy system. Thanks for your help --000e0cd17c98f189d2047bd7de2a--