では、データベースに保存されている「データエンティティ」またはモデルごとに作成するCouchDB必要がありますか？design documentsまたは、必要なすべてのビューのビューを含む1つの設計ドキュメントが必要ですか？
たとえば、データベースにいくつかのUsersandがある場合Comments、単一の設計ドキュメントが呼び出される可能性があり、その中に、、、などの_design/blog名前のビューがあります。usersByNamecommentsByDate
または、、などの名前のビューを持つ、、などの個別の設計ドキュメントを用意する必要が_design/usersありますか？_design/commentsbyNamebyDate
それは良い質問です。デザインドキュメント自体は、ビュー、リスト、表示、更新機能のコレクションにすぎません。「アプリケーション層」のすべての作業は、これらの機能によって実行されます。したがって、エンティティごとに異なる設計ドキュメントをこれらの機能で分離する必要があります。質問で概説したブログシナリオは、設計ドキュメントの使用方法の優れた例です。
デザインドキュメントをアプリケーションのファイル構造と考えてください。他のフレームワークを使用してアプリケーションを構築している場合、アプリケーションのファイル構造はおそらく1つだけです。ちなみに、で複数のデザインドキュメントを作成することを妨げるものは何もありません。アプリケーションですが、この方法では少し手に負えなくなると思います。
要約すると
個別のビューを備えたアプリケーションごとに1つの設計ドキュメント、必要に応じて機能を表示します。