couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Ragan <dale.ra...@sinesignal.com>
Subject Re: Would there be a problem with storing documents with this structure?
Date Mon, 31 Aug 2009 00:46:30 GMT
Chris Anderson wrote:
> On Sun, Aug 30, 2009 at 5:10 PM, Tom Sante<tom.sante@gmail.com>  wrote:
>    
>> 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.
>>      
>
> if you put the manager_id on the worker, then you can pull out a
> manager and all it's workers in a single query if you like, using just
> a map view.
>
> here's the canonical write up of the technique:
>
> http://www.cmlenz.net/archives/2007/10/couchdb-joins
>
>    
Thanks for the link, I understand about normalizing the data.  I picked 
a poor example to answer the question I
am really after.  Basically, is there any problem with wrapping the 
Manager in the way that I did?  With it being
nested as a value for Content?  Instead of the Manager properties being 
on the first level like this, I took the Subordinates
out for clarity:

{
  "_id":"000144df-6f11-49f1-a502-e0dab3592326",
  "_rev":"1-308931e16105b566e1fb48106c85116e",
  "type":"Manager",
  "Name":"6",
  "Login":"6-login"
}

>> 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.
>>
>>      
>
>
>
>    

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message