在CouchDB权威指南（here）中阅读本段后：
如果您有多个设计文档，每个文档都带有validate_doc_update函数，则每次传入的写入请求都会调用所有这些函数。只有当所有这些都通过时，写入才会成功。未定义验证执行的顺序。每个验证功能必须独立运作。
我想知道是否有任何好的做法来处理多个validate_doc_update函数？
我的意思是：只创建一个带有validate_doc_update字段或有几个较小字段的设计文档会更好吗？
在第一种情况下，可以确定没有任何验证函数会干扰另一个验证函数，但如果需要大量控件，函数可能会变得非常大。
另一方面，几个较小的功能可能更容易阅读和演变，但必须确定每个功能的目的，而不是与其他功能混淆。
另外，让每个设计文档都具有验证功能的重点是什么？例如，在视图文档中存储一个看起来有点脏，但是为了保存一个小的验证函数而创建几个设计文档对我来说似乎也不是很聪明。
您怎么看？
我可能错过了一些内容，这就是我的问题所在，是否有关于管理多个validate_doc_update函数的良好做法？
答案 0 :(得分：11)
注意，我写了引用的段落。
一般来说，我看到应用程序和设计文档之间存在1：1的相关性。单个应用程序所需的一切都应该在一个设计文档中。较大的应用程序可能因各种原因（例如不同的视图组）而希望依赖多个设计文档，但一般来说，每个应用程序的一个设计文档是一个很好的经验法则。
现在，每个数据库可能有多个应用程序。例如。 CMS：一个应用程序可以是面向公众的CMS查看应用程序，另一个应用程序可以是管理界面。您希望将它们分开，因为它们是两个不同的应用程序，它们对相同的数据进行操作并将它们分开是一个很好的组织理念。不同的安全机制适用，因此您有两个验证函数可以实现适用于相应应用程序的功能。
引用的paragraphis你所拥有的案例的定义（无论出于何种原因）每个数据库都有多个设计文档。它解释了期待什么。它并不是指导如何分解的指导原则。按照每个应用程序的经验法则使用一个设计文档，大多数时候你都很好。
答案 1 :(得分：6)
我知道已经选择了一个答案，但我至少会抛弃我关于此事的做法作为替代方案。
我决定不再仅仅建立纯粹的CouchApps，至少是暂时的。 （我已经决定将Node.JS作为我的新中间件层）考虑到这一点，我从CouchDB设计文档中获得了更多的灵活性。
我已经为数据库中的每个实体设计了单独的设计文档。因此，每个设计文档都包含它自己的视图，验证函数，更新处理程序等。为了回答您的问题，每个验证函数只处理我的数据库中的一个实体，这使它更有针对性，更易于管理。