Optimization 沙发数据库-复杂键和视图冗余

试图让这个问题尽可能简单。。。我目前正在考虑使用两个（coach）数据库视图

第一个的签名看起来有点像这样

{[username, group], value}

我可以用-startkey=[username]&endkey[username，{}查询它

两种观点中的第二种看起来像

{[group, username], value}

我可以用-startkey=[group]&endkey[group，{}来查询它

好吧，我不能用-startkey=[{}，propertyName]&endkey[{}，propertyName]查询视图，这就是为什么我觉得需要两个视图。但问题是，创建两个键看起来如此相似的视图感觉有多麻烦。当然，最大的优势是，这两个视图中的一个将为我提供一个简单、直观的用户名搜索，而另一个将对组执行相同的搜索

然而，这两个组都允许我使用reduce函数来识别每个组中唯一的用户名

TLDR

---

我可以只使用一个视图来唯一标识每个组中的用户数，或者使用键“组”或“用户名”属性来查询它吗？

不可以，因为视图下面的B-树是按索引键从第一个到最后一个排序的，因此不允许按次搜索，第三级等等键，除非前面的键也存在。这类似于在RDBMS中添加索引，因为它们的基础是相同的B树结构。在RDBMS中，查询使用的索引必须至少包含索引的第一个键。不使用第一个键执行查询将导致表扫描（假设没有更好的索引存在），而以这种方式“查询”CouchDb视图只会导致没有结果。因此，CouchDb的视图是显式索引，不需要对所有文档进行扫描

根据我的经验，在与CouchDb合作时，感觉有一种内在的倾向，即大量增加视图，但实际上它只是迫使我们真正考虑搜索，因为没有内在的回退