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 morbus@disobey.com designates
 65.23.129.70 as permitted sender)
Message-ID: <4A5767A5.9050509@disobey.com>
Date: Fri, 10 Jul 2009 12:09:09 -0400
From: Morbus Iff <morbus@disobey.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: Defining my document model when the source is entity-relationship
References: <4A5632F8.5040406@disobey.com>
 <634e096f0907100831k7ba94613k53fd2247265adecd@mail.gmail.com>
In-Reply-To: <634e096f0907100831k7ba94613k53fd2247265adecd@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

> 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

Yeah, how I'm gonna handle relationships is the next major thing I've 
got to figure out. FRBR has its own concept of relationships, too, and 
I'm potentially leaning toward creating a "relationship" document type 
that handles them all back and forth. I can't help but feel I'm 
replicating too much of a relational database, were I to do that, but I 
fear how complex a map/reduce view would be with all these different 
document types floating around, cf. Damien's View Collation:

   http://www.cmlenz.net/archives/2007/10/couchdb-joins

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

Say what now?

> 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

This is a good point - the replication part of a CouchApp (which I have 
only just started to learn about) is very appealing to me. The fact that 
I can only use HTML/JS also adds another layer of "Sounds like a Fun 
Challenge". I just didn't anticipate how much of an "interesting 
problem" an FRBR attempt has created ;)

> How far do you want to take your pet project?

Why do I get myself into things like this? ;)

-- 
Morbus Iff ( earth? shxt and scrambled eggs. earth? )
Technical: http://www.oreillynet.com/pub/au/779
Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/
aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus