On Wed, Aug 5, 2009 at 7:40 PM, william cinnebar<[email protected]> wrote: > Chris: thanks for the fast reply and thanks for the incredible amount of > work you are doing towards development of couchdb > > > to further clarify... > > Referential integrity falls to the method/function/processes of an > application that is using the data stored in a couchdb db file rather than > any inbuilt couchdb method/function/process. > > Normal/denormal is relevant to the structure of rdbms where sql would > typically be used to query the data. Essentially how 'self contained' a > document may be in couchdb is relative to specific use cases of > application/s that access the db file. > > ...normal/denormal has little if any actual relevance to document structures > or patterns of document management used within couchdb?
You've mostly got it here. However, there is a strong relevance regarding document granularity. "Singleton" documents (like a master list of all employees and their projects in one document) are too denormalized, because the chances of 2 users editing them at the same time are too high. On the other hand, completely normalized would mean you'd have to load lots of documents to make any sensible screens in your application. So I tend to break up my documents around concurrent editing patterns. It's not a hard and fast rule but it has more pragmatic relevance in CouchDB's case. You certainly don't want N automated processes all attempting to change the same document multiple times a second. For that it's better to create a new document for each event and use a view to pull out or the total state. > > CouchApp is an abbreviated way of saying 'couchdb standalone application'. > > Any 'couchdb standalone application' is a CouchApp. > > My two cents says the core documentation for _ids and _revs is strong but > thanks for reiterating anyways... > > > cheers > -- Chris Anderson http://jchrisa.net http://couch.io
