Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of tom.sante@gmail.com
 designates 74.125.78.24 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=date:from:to:subject:message-id:references:mime-version
         :content-type:content-disposition:in-reply-to:user-agent;
        b=eKzGua4kxo0OiTTGuXEiAQAc+vDi+lCfhRxg6x2OECiOoIT5fUhd4UPhwifDs1ZKWE
         PCzYHWFi5Y64nzLHT+Oh6Njneo6DM0pLn5NQJ90Z1akGAHp2XA+r/YL5pQLbPusWguTD
         CNQmpByb0+qj0apqlmPWp5cXBgVzTm8zh+cw4=
Date: Mon, 31 Aug 2009 02:10:02 +0200
From: Tom Sante <tom.sante@gmail.com>
To: user@couchdb.apache.org
Subject: Re: Would there be a problem with storing documents with this
 structure?
Message-ID: <20090831001002.GA555@pb.local>
References: <4A9AD394.20608@sinesignal.com>
 <7B8A7655-B750-4B0B-93BB-A48FE8C47A9E@bzero.se>
 <4A9B070C.1030207@sinesignal.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A9B070C.1030207@sinesignal.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

On Sun, Aug 30, 19:11, Dale Ragan wrote:
> >
> >>Basically I have a document, with an id, rev, type, and Content
> >>keys.  The Content key
> >>holds the serialized object that is to be stored for it's value.
> >>Are there any pitfalls
> >>with this design?  I have attached a sample below:
> >I should say I'm in no way an expert, I'm starting to wrap my head
> >around document modelling myself. I've been reading up on couchdb
> >a couple of days now and find it really interesting.
> >
> >Anyway, on to your document. First, why duplicate the manager id?
> >Isn't there a risk of them getting out of sync?
> There is no chance that the Id's will get out of sync. I handle
> generating the Id's when the object is persisted for the first time.
> >
> >I think you will run into many conflicts if subordinates are
> >updated independently. Each subordinate has an id, is there
> >another document with more information about subordinates? In that
> >case, why not have all information in there and connect them with
> >a managerId attribute instead?
> This is just an example object that I modeled up for the post.
> Subordinates in this case are updated another way.  They are just
> referenced by the Manager object.  Basically, a one-to-many
> relationship.  If you wanted to update one, you would use a document
> that wrapped the Worker object.  Is it better to normalize the data
> even in CouchDB?
> 
> I am new to CouchDB also.  I am trying to abstract any need for a
> domain model needing to know about CouchDB's terms, like Rev.  I am
> writing an API in a statically typed language and I am experimenting
> with the best way to store the object that is given to my API.  This
> design helps and is one of the few I have come up with.
> 
> - Dale
> >>{
> >>  "|_id|":|"000144df-6f11-49f1-a502-e0dab3592326"|,
> >>  "|_rev|":|"1-308931e16105b566e1fb48106c85116e"|,
> >>  "|type|":|"Manager"|,
> >>  "|Content|": {
> >>      "|Subordinates|": [
> >>          {
> >>              "|Address|": {
> >>                  "|Street|":|"123 Somewhere St."|,
> >>                  "|City|":|"Kalamazoo"|,
> >>                  "|State|":|"MI"|,
> >>                  "|Zip|":|"12345"|
> >>              },
> >>              "|Hours|":|40|,
> >>              "|Id|":|"6bcdea2f-2439-4785-ab59-2ee612435705"|,
> >>              "|Name|":|"Bob"|,
> >>              "|Login|":|"bbob"|
> >>          },
> >>          {
> >>              "|Address|": {
> >>                  "|Street|":|"123 Somewhere St."|,
> >>                  "|City|":|"Kalamazoo"|,
> >>                  "|State|":|"MI"|,
> >>                  "|Zip|":|"12345"|
> >>              },
> >>              "|Hours|":|40|,
> >>              "|Id|":|"b0d156c9-ea3f-4c4f-b49d-ab19bff64dd8"|,
> >>              "|Name|":|"Alice"|,
> >>              "|Login|":|"aalice"|
> >>          },
> >>          {
> >>              "|Address|": {
> >>                  "|Street|":|"123 Somewhere St."|,
> >>                  "|City|":|"Kalamazoo"|,
> >>                  "|State|":|"MI"|,
> >>                  "|Zip|":|"12345"|
> >>              },
> >>              "|Hours|":|20|,
> >>              "|Id|":|"12b6dbbc-44e8-43c2-8142-11fc6c1d23df"|,
> >>              "|Name|":|"Eve"|,
> >>              "|Login|":|"eeve"|
> >>          }
> >>      ],
> >>      "|Id|":|"000144df-6f11-49f1-a502-e0dab3592326"|,
> >>      "|Name|":|"6"|,
> >>      "|Login|":|"6-login"|
> >>  }
> >>}
> >>
> >>Basically the content is a Manager type object with an Id, Name,
> >>Login, and Subordinates.
> >>Subordinates are Worker's with an Id, Name, Login, Hours, and an
> >>Address.  The _id and the Id of
> >>the Manager object are the same.  Basically the Document object
> >>is just a wrapper around what is
> >>given to be persisted.
> >>
> >>Thanks,
> >>
> >>Dale

Like Martin said why all this duplication?
Give each worker it's own document and only add the id's of the
workers as subordinates. So you can change worker details without
having to change the manager document. 

It might even be better to only store the managers own info in the
manager doc and save any worker-manager relations in the respective
worker document by referencing the manager id in the worker doc + how
many hours he worked for that manager.
This makes it easier if a worker changes to work for another manager you
just reference the manager id in worker doc still keeping the history
of previous other managers that worker had in the past.