Re: Would there be a problem with storing documents with this structure?

Sun, 30 Aug 2009 17:47:05 -0700 

Chris Anderson wrote:

On Sun, Aug 30, 2009 at 5:10 PM, Tom Sante<[email protected]>  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.

Reply via email to