Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 80460 invoked from network); 1 Jun 2010 03:47:48 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Jun 2010 03:47:48 -0000 Received: (qmail 92639 invoked by uid 500); 1 Jun 2010 03:47:47 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 92443 invoked by uid 500); 1 Jun 2010 03:47:47 -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 92425 invoked by uid 99); 1 Jun 2010 03:47:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jun 2010 03:47:46 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com designates 209.85.212.52 as permitted sender) Received: from [209.85.212.52] (HELO mail-vw0-f52.google.com) (209.85.212.52) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Jun 2010 03:40:16 +0000 Received: by vws18 with SMTP id 18so5066678vws.11 for ; Mon, 31 May 2010 20:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=aDXUQRVK9J2O+AdgjW9Ad0Z1yE5xpkpAy1j37z7AD9I=; b=rDupCJmxVWiFpk4Kk6c84vqms+wB2wReTITBvSinsM/eVaJxwiViqs8Tz5/KjqZACE cxTxkfinD3hn4aMR5yGQf41BdrPNervNTECC71CpeXR1e3EziFOT/ioG9O+hsawOkJJV 0XyR1a9bnHwSf2QljOfR/AEeFWtVrpmINT/rg= 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; b=WFvI5/truk2t4HCXM7C15VeJWQit6QiDAq9z1ViObV7wXaqL8RX8Fj3AZCw3jJ/axx TCGXoj8RqpD65qPS5a8iuzci/gZpSZajCwE/SGOnQcqf96qJx4PGC6s4kBRGbKGeRmqo LjQC9/+XQVZDAndhXFUjSuNov2uANA5ibeQjY= MIME-Version: 1.0 Received: by 10.224.35.206 with SMTP id q14mr2064728qad.146.1275363594456; Mon, 31 May 2010 20:39:54 -0700 (PDT) Received: by 10.229.6.10 with HTTP; Mon, 31 May 2010 20:39:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 May 2010 20:39:54 -0700 Message-ID: Subject: Re: business model / 'ER' help From: Randall Leeds To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org The easiest thing in my mind would be to have a document for each inventory item that contains its name and the store where it's in stock. This is actually kinda nice because it lets you track individual instances of each item, like if you wanted to order the item to be sent from one store to another you could modify the store property. I think you can get away with only two map functions. Make one map that emits a key like {[item, store]: item_id}. Call it "items_by_name". Another map emits keys like {[store, item]: item_id}. Call it "items_by_store". Then all three of your questions are simple summation ({"reduce": "_count"}) reductions. 1. _design/inventory/_view/items_by_name?group=true&group_level=1 2. _design/inventory/_view/items_by_name?group=true&group_level=2&startkey="[item_name]"&endkey="[item_name, {}]" 3. _design/inventory/_view/items_by_store?group=true&group_level=2&startkey="[store_name]"&endkey="[store_name, {}]" I think this would work for you. You might need to url encode those keys. The startkey and endkey parameters are chosen based on the collation specification[1]. Happy map(-reduc)ing! -Randall [1] http://wiki.apache.org/couchdb/View_collation?action=show&redirect=ViewCollation#Collation_Specification On Mon, May 31, 2010 at 20:14, wrote: > Hi I am trying to get my head around a simple practice task, however I > can't stop thinking about relational models as opposed to document models > hehe > > ok so i have one couchDB database that has to contain 3 stores, each store > has a product inventory (i.e product name, qty) > > I have to be able to: > > 1. list the total qty of each item (i.e across all stores) > 2. list the QTY of a certain item within each store > 3. list all items, their qty for a specific store > > ...I could smash this out in SQL in a few minutes...but cant get my head > around doing it as documents....eg would I have a document for each store > containing product attributes(i.e p1, p2 etc)? or a document for each > product containing store attributes(i.e P > s1-qty, s2-qty, s3-qty)? > > or (and i doubt this be true) would i have separate store docs and product > docs and somehow link then like I would in a 'real' (:-p) database lol > > wasnt sure if these kinds of Q's were asked in here so thought id just > give it a shot >