couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "EntityRelationship" by WoutMertens
Date Sun, 19 Apr 2009 15:42:19 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The following page has been changed by WoutMertens:
http://wiki.apache.org/couchdb/EntityRelationship

The comment on the change is:
Added Jason Smith's comments

------------------------------------------------------------------------------
  = Modeling Entity Relationships in CouchDB =
  
- This page is mostly a translation of Google's [http://code.google.com/appengine/articles/modeling.html
Modeling Entity Relationships] article in CouchDB terms. I (WoutMertens) am mostly happy with
it but it could use more code examples and more examples of actual output. Since this is a
wiki, feel free to update this document to make things clearer, fix inaccuracies etc. This
article is also related to [http://wiki.apache.org/couchdb/Transaction_model_use_cases Transaction
model use cases] discussion, as it involves multiple document updates.
+ This page is mostly a translation of Google's [http://code.google.com/appengine/articles/modeling.html
Modeling Entity Relationships] article in CouchDB terms. It could use more code examples and
more examples of actual output. Since this is a wiki, feel free to update this document to
make things clearer, fix inaccuracies etc. This article is also related to [http://wiki.apache.org/couchdb/Transaction_model_use_cases
Transaction model use cases] discussion, as it involves multiple document updates.
  
  As a quick summary, this document explains how to do things that you would normally use
SQL JOIN for.
  
@@ -101, +101 @@

  }
  }}}
  
- or even
+ or even more succinctly
  
  {{{
  {
@@ -177, +177 @@

   * ''include_docs=true''
  You'll get all documents that are pertinent to the group, but in no particular order. The
size of your index will be smaller though.
  
- In general though, you want to avoid storing overly large lists of any kind in a single
document. The reason is that if your document becomes, say 1MB in size, then you need to upload
1MB to the database every time you want to make a change to any part of the document. Therefore
you should place the list on side of the relationship which you expect to have fewer values.
In the example above, the Contact side was chosen because a single person is not likely to
belong to too many groups, whereas in a large contacts database, a group might contain hundreds
of members.
+ For the most efficient changes to the relationship list, you should place the list on side
of the relationship which you expect to have fewer values. In the example above, the Contact
side was chosen because a single person is not likely to belong to too many groups, whereas
in a large contacts database, a group might contain hundreds of members.
  
  === Many to Many: Relationship documents ===
  
- Another way of implementing many-to-many is by creating a separate document for each relationship.
A document explaining that Scott is a Friend would look like
+ Another way of implementing many-to-many is by creating a separate document for each relationship.
+ 
+ You would use this method if you modify the key list frequently (i.e. if you get more conflicts
than is acceptable), or if the key list is so large that transferring the document is unacceptably
slow. Relationship documents enable frequent changes with less chance of conflict; however,
you can access neither the contact nor group information in one request. You must re-request
those specific documents by ID, keeping in mind that they may change or be deleted in the
interim.
+ 
+ A document explaining that Scott is a Friend would look like
  {{{
  {
    "_id":"some unique id",

Mime
View raw message