Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 29BD8DCAB for ; Thu, 12 Jul 2012 09:04:22 +0000 (UTC) Received: (qmail 97569 invoked by uid 500); 12 Jul 2012 09:04:21 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 97539 invoked by uid 500); 12 Jul 2012 09:04:20 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 97497 invoked by uid 99); 12 Jul 2012 09:04:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jul 2012 09:04:18 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of space.ship.traveller@gmail.com designates 209.85.215.180 as permitted sender) Received: from [209.85.215.180] (HELO mail-ey0-f180.google.com) (209.85.215.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jul 2012 09:04:11 +0000 Received: by eaai12 with SMTP id i12so632517eaa.11 for ; Thu, 12 Jul 2012 02:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TNfw4mTiA0qsuLh3BO+yuTTKIQB3dKcKHwp0RlvlssE=; b=G4kGy/2HjUHE7A/FzENyKlj1OsdtcoJd2Hli6WHJnUm89sMicxyIhAC3AXozzOrmxl 1QZG6/YTtK17IMspLXtP7is06HU2usq54bnxHTmY5YDTV5PAqyVhAoKgJ6h0BtBi5XBX sk6Yj8bmqPoorN6tKUEp6GvRGq3JADfP5Ye8RqGtKpxQ1G7xlSHccurtQlM8QXLUe+rR o2E/8fmkpZoWIffR9oCunC74iih8G4eybh9il3U19cTvbAGzKmd3pmgOdN9IU/UcCI2l xItoHHZsGHeqbVASRqhsUiiIAmN1x2AGdPivnRUkCDHC9+uphAEmqzd+JLCUd83PeyGl oXfQ== MIME-Version: 1.0 Received: by 10.14.101.72 with SMTP id a48mr12850791eeg.120.1342083830496; Thu, 12 Jul 2012 02:03:50 -0700 (PDT) Received: by 10.14.176.197 with HTTP; Thu, 12 Jul 2012 02:03:50 -0700 (PDT) Date: Thu, 12 Jul 2012 21:03:50 +1200 Message-ID: Subject: Data modelling From: Samuel Williams To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=bcaec521580df9c09304c49e3db2 --bcaec521580df9c09304c49e3db2 Content-Type: text/plain; charset=ISO-8859-1 Hi, I need to model some relationships. (1) With a one-to-many relationship, should I keep the keys of the many objects in the one, or for each many object have the key of the one, or both? e.g. {"_id": "bank-account-1", ..., transactions: ["transaction-key-1", "transaction-key-2", "transaction-key-3"]} {"_id": "transaction-key-1", ...} {"_id": "transaction-key-2", ...} {"_id": "transaction-key-3", ...} OR {"_id": "bank-account-1", ...} {"_id": "transaction-key-1", ..., "bank-account": "bank-account-1"} {"_id": "transaction-key-2", ..., "bank-account": "bank-account-1"} {"_id": "transaction-key-3", ..., "bank-account": "bank-account-1"} Both are a possibility. However, with the first approach, the document may get very large. This leads into my next question: (2) W.r.t. denormalizing data - sometimes it naturally makes sense, e.g. invoice with multiple line items stored in an array vs invoice with multiple line item documents. With an invoice, once you make the invoice it doesn't usually change that much and you also want the data together when you access it, e.g. to display, however with a bank account the transactions are changing frequently (e.g. new transactions every day). I was wondering if I should consider batching together transactions, e.g. a document for each month's worth of transactions, or perhaps one per year, etc. That way when modifying transactions, you don't need to specify the entire huge document with 1000s of individual items. I would appreciate any feedback and suggestions/advice. Thanks Samuel --bcaec521580df9c09304c49e3db2--