CouchDb-一个具有多个视图的设计文档与多个具有拆分视图的设计文档

我正试图找出这两者之间的权衡

似乎使用一个具有多个视图的设计文档更新速度很快，因为在编制索引时，每个文档都在一次传递中传递到每个视图中

但是，如果我在设计文档中更改了一个视图，那么所有视图都需要更新

---

这似乎正确吗？是否有其他人可以补充这一理解？

更多详细信息可以找到：

视图被组织到设计文档中。理论上，一个数据库中可以有任意多个设计文档，一个设计文档中可以有任意多个视图。理论上，每个视图可以在每个文档中发出任意多个b树节点，并且您的map/reduce代码可以任意复杂。但请记住：

• 拥有多个视图会降低性能，因为每个视图都必须在每次文档更改时运行
• 将同一设计文档中的所有视图索引在一起；更改、添加或删除任何视图都需要对所有视图重新编制索引

• 在一个视图中，每个文档有多个发射可能会降低性能（但性能略高于将每个发射放在自己的视图中）

• 复杂的映射和缩减代码会降低性能

• 发出非null值会降低性能
• 使用reduce代码而不是内置的_sum、_count、_stats会降低性能

作为旁注，CouchDB和Cloudant在视图更新的确切时间上有所不同：

• CouchDB延迟更新视图，即在查询视图时更新视图。这可能导致不常访问的视图等待时间过长
• Cloudant在后台异步更新视图。这意味着不再访问的视图仍在消耗系统资源

---

该链接文章中的另一段相关引用：“将每个视图放在自己的设计文档中，这样每个视图都可以单独重新编制索引。（请记住，即使删除一个视图，如果它与其他视图一起放在设计文档中，也会导致重大的重新编制索引！）”