incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Unkovsky <>
Subject Re: Defining my document model when the source is entity-relationship
Date Fri, 10 Jul 2009 12:25:24 GMT
You bring a very interesting case to couchdb.
Some thoughts are that proper blance of "schemaless" scheme is between
embedded documents (fields) and document-to-document relations, that
can be expressed as graph with documents as nodes and relations as
The difference between this relations and sql-relations could be their
lazy evolvement and co-existance with more old-schemed documents.

I'm really starting to become convinced that we need some graph
indexer to traverse relations in couchdb for such applications.

Then, probably, nice way to implement the case is to start with some
small entities, add fields to them, and then, based on usage
statistics separate embedded fields from containing nodes replacing
with references.
May be, it's not quite possible with current state of things with
couch, but it's a way for thought I'll have on mind all further time.

Thank you for very interesting case!

I'll give it another think, maybe such approach is implementable in
some way just now.

2009/7/10 Morbus Iff <>:
>> 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.

View raw message