Question

What is the difference between views as a stand-alone design documents and views grouped in one design document? When do you put two views in one design document? Is there any guide for this?

Answer 1

There’s no real guide for this, as it’s entirely up to you. Here are the implications as far as I can tell:

Each design document can have as many (or as few) views as you wish. Keep in mind that a view is not created or updated until it is first queried. Also, when a single view is queried, all the other views in that same design document will also be created/updated. This won’t be a problem unless you have millions of documents, but it is something to bear in mind.

Also, I believe the full string value of the view is compared between revisions, so it won’t rebuild a view if the name and function text are identical. (NOTE this is speculation based on what I’ve read about views, it’s just never explicitly stated)

Generally, I’ve migrated towards having a “common” design document that contains a lot of the core CommonJS modules (like form validation functions) and other general settings. In addition, each “entity” in my project will have a separate design document with their own views, update handlers, validation functions, show/list functions, etc. This pattern keeps each entity and it’s functions grouped together, almost like a class of sorts. I’ve found it is much easier to maintain and naming is a little easier when each entity is self-contained.