On Fri, Jul 10, 2009 at 5:40 AM, Morbus Iff<[email protected]> 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. Chris > >> 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 file...@! ) > 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 > -- Chris Anderson http://jchrisa.net http://couch.io
