incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freddy Bowen <frederick.bo...@gmail.com>
Subject Re: Defining my document model when the source is entity-relationship
Date Fri, 10 Jul 2009 15:31:15 GMT
You bring an interesting problem Morbus.  My take is this...

On Thu, Jul 9, 2009 at 2:12 PM, Morbus Iff <morbus@disobey.com> wrote:

>   * Should all these Group entities be individual docs...
>  * ... or should they all be a single document inside CouchDB?


Group entities should be individually "typed" docs in CouchDB.  The
relations should be individually "typed" docs too.  Cleverly indexing all
these docs for straight-forward use with map/reduce views would be the
trick.

I use a CouchDB doc to represent the pragmatic intersection between single
coherent data nugget and interrelated data nuggets that can
created/queried/updated as a block without contention, conflict, or
performance degradation exceeding my threshold for pain.

In your case, to represent all Group1 entities as a single doc could create
a situation, in a distributed/replicated CouchDB network, where a WEMI could
be modified at the same time on ten different Couches, replicated, and
result in a big WEMI mess.  If this WEMI represents the Starr report the day
it was released that could be a big problem.  If it represents a less
volitile WEMI then maybe the chances of a conflict or a resolution process
is an acceptable trade-off.

Alternatively, representing all Group1 entities as individual docs with
individual relation docs mitigates against totally conflicting WEMIs but
allows partially conflicting WEMIs (conflicting relations or individual
entities).  I suspect that, in a distributed/replicated CouchDB network,
partially conflicting WEMIs might be entirely acceptable.  But, as I
previously said, implimentating all these docs and relations in current
CouchDB HEAD would require some ingenuity.

How far do you want to take your pet project?

-FB

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