couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dionne <dio...@dionne-associates.com>
Subject Re: Defining my document model when the source is entity-relationship
Date Fri, 10 Jul 2009 12:17:02 GMT





On Jul 10, 2009, at 7:44 AM, Morbus Iff wrote:

>> I think it might be useful to go with your first instincts, that a   
>> book is a document, and then see how to best organize the  
>> information  you have about the book in support of some  
>> application, rather than
>
> But, in the FRBR model, the "book" (FRBR's "Manifestation") is not  
> the "final" or "complete" document (CouchDB's "document"). Were I to  
> strictly map "the book is a document", the CouchDB document would be  
> a "Work" comprising *hundreds* of different Expressions and  
> Manifestations and Items, forever spidering out. Consider "The  
> Hobbit" (a famous thought-experiment for FRBR) - it'd be one  
> mightily huge, single, JSON document, comprising every edition of  
> every book, every CD, every Rankin-Bass iteration on TV, VHS, and  
> DVD, the forthcoming 2011 movie, the two video games made for it,  
> etc., etc. The singular artistic endeavor that is "The Hobbit" is a  
> lot more than a single book - it's a very complex stress test for  
> any FRBR application.

actually I'm not talking about "The Hobbit" as a concept, a class of  
individuals comprising all the books, CDs, YouTube videos, etc., I was  
referring to the "The Hobbit", the green volume sitting on my shelf  
with an n-bit address in the universe that my dog chewed.

As the FRBR modelers point out, the entities are easy but figuring out  
all the relations is hard. There are so many, and they depend largely  
on a world view. For example, I have this customer with a moving  
business, she specializes in moving books. In her schema all that's  
needed is height, width, depth, and weight. All this "Work",  
"Manifestation", ISBN-code stuff is just fluff.

One way to view documents is to consider them like rows in a table  
where you can have as many columns as you like.




>
>  http://www.frbr.org/2006/08/19
>
> It would fit into CouchDB's model to have a JSON document this  
> large? It would grow ever larger if a user ever used the application  
> too - every user who owned a copy (an Item) of a "The Hobbit"  
> Manifestation (a book, a CD, a VHS, etc.) would add on an FRBR Item  
> to the existing JSON document, which itself may have numerous fields  
> and tags and etc.
>
> It would be easily safe to say that, for an FRBR mockup of "The  
> Hobbit" in a single JSON document, the JSON document would have  
> thousands of objects, and then an additional object for each user  
> who ever owned it.
>
> Is that "OK", whilst still allowing for quick lookups against it,  
> and allowing me to load a particular "The Hobbit" Manifestation (or  
> the entire Work, as necessary), without loading, say, all the Item  
> objects?
>
> Ignoring FRBR entirely, I suppose the question is: how large can
> a CouchDB JSON document get before it stops being useful?
>
> -- 
> Morbus Iff ( i subscribe to the theory of intellectual osmosis )
> 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


Mime
View raw message