Principles for Modeling CouchDB Documents

Question

I have a question that I\'ve been trying to answer for some time now but can\'t figure out:

How do you design, or divide up, CouchDB documents?

Take a Blog P

Answer 1

The book says, if I recall correctly, to denormalize until "it hurts", while keeping in mind the frequency with which your documents might be updated.

1. What rules/principles do you use to divide up your documents (relationships, etc)?

As a rule of thumb, I include all data that is needed to display a page regarding the item in question. In other words, everything you would print on a real-world piece of paper that you would hand to somebody. E.g. a stock quote document would include the name of the company, the exchange, the currency, in addition to the numbers; a contract document would include the names and addresses of the counterparties, all information on dates and signatories. But stock quotes from distinct dates would form separate documents, separate contracts would form separate documents.

2. Is it okay to put the entire site into one document?

No, that would be silly, because:

• you would have to read and write the whole site (the document) on each update, and that is very inefficient;
• you would not benefit from any view caching.