如何为以下案例设计 couchdb 视图？答案

【问题标题】：How do I design a couchdb view for following case ?如何为以下案例设计 couchdb 视图？
【发布时间】：2011-10-12 08:08:29
【问题描述】：

我正在将应用程序从 mySQL 迁移到 couchDB。（好吧，请不要对此作出判断）。

有一个带有签名的函数

getUserBy($column, $value)

现在您可以看到，对于 SQL，构建查询并触发它是一项微不足道的工作。

但是就 couchDB 而言，我应该使用地图函数编写视图

目前我有很多观点，例如

get_user_by_name
get_user_by_email

等等。任何人都可以提出一种更好且可扩展的方法吗？

【问题讨论】：

标签： couchdb mapreduce

【解决方案1】：

当然！我最喜欢的观点之一是by_field。这是一个非常简单的地图功能。

function(doc) {
    // by_field: map function
    // A single view for every field in every document!
    var field, key;

    for (field in doc) {
        key = [field, doc[field]];
        emit(key, 1);
    }
}

假设您的文档有一个 .name 字段作为他们的姓名，.email 作为他们的电子邮件地址。

按名称获取用户（例如“Alice”和“Bob”）：

GET /db/_design/example/_view/by_field?include_docs=true&key=["name","Alice"]
GET /db/_design/example/_view/by_field?include_docs=true&key=["name","Bob"]

通过电子邮件获取用户，从相同的角度：

GET /db/_design/example/_view/by_field?include_docs=true&key=["email","alice@gmail.com"]
GET /db/_design/example/_view/by_field?include_docs=true&key=["name","bob@gmail.com"]

我喜欢发出1 的原因是您可以稍后编写reduce 函数以使用sum() 轻松添加与您的查询匹配的文档。

【讨论】：

这就是我解决这个问题的方法，但我关心的是可扩展性。对于具有 m 个字段的 n 个文档，每个文档输出大约 n*m 行。我不熟悉 CouchDB 的内部结构，但作为一个 mysql 人，我想知道这是否会占用很长时间。
最初调用视图可能需要一些时间，但视图结果会被缓存，因此再次查询视图时只考虑更新的文档。
另外，如果您不需要每个字段输出，您可以修改上面的“by_field” MapReduce 以仅输出您（或计划）感兴趣的字段。在您的 n*m方程，m 将是您关心的字段数。也就是说，让它“全开”确实会给你更多的灵活性，但代价是视图索引（gre 提到的结果缓存）使用的更多磁盘空间（尽管相对最小）。