couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Defining my document model when the source is entity-relationship
Date Fri, 10 Jul 2009 18:02:04 GMT
On Fri, Jul 10, 2009 at 5:40 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
>> 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.
> Ok, so, if we establish that:
>  * I /do/ want to use the FRBR model of W, E, M, I. That's the goal,
>   not "making a book database for some moving book customer"...
>  * ... and you were talking about a "book as [CouchDB]
>   document" as a copy of your "The Hobbit" on the shelf...
> then that leaves me with an inferred statement of:
>  * Make a CouchDB document model an FRBR Item.
> which further asserts that the other Group 1 entities of FRBR (W, E, M,
> which again is what /I/ want, not a generic book database that we've seen a
> thousand times before) should also be modeled as specific CouchDB documents.
> Is that right?

I'm not sure how this helps, but basing your schema around user events
is often the right way to go. So if a user wants to record the fact
that they have a copy of The Hobbit, they wouldn't touch the existing
Hobbit doc, they'd create a record of the fact that they have The
Hobbit, and use a view to pull out lists like "all books I own".

The unit for dividing documents is essentially concurrency. Since you
know many users may be getting a copy of The Hobbit at around the same
time, you don't want them editing the main document. You may want to
split The Hobbit's main document along these lines as well. Maybe WEMI
would each be it's own document...

Modeling to avoid update-conflicts I think will give you the balance
between normalized enough and too normalized.


>> 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.
> Sure, but I assert (again, though I ended up deleting it from the previous
> e-mail just prior to sending it) that this is a usability problem, not a
> data model problem. Even the FRBR stuff states, somewhere somehow, that the
> model isn't usable (or necessary) for "normal" people.  In my view, she'd
> never even see, or need to know, the concepts of WEMI in her using the app.
> IO would be friendly, regardless of the model.
>> One way to view documents is to consider them like rows in a table  where
>> you can have as many columns as you like.
> Which also supports the "make each Group 1
> entity a CouchDB document type" assertion?
> --
> Morbus Iff ( HOW DO I DELIT TEH TREE FILEZ?!@! )
> Technical:
> Enjoy: and
> aim: akaMorbus / skype: morbusiff / icq: 2927491 / morbus

Chris Anderson

View raw message