4

我来自一个 SQL 世界，其中查找由多个对象属性（published = TRUE 或 user_id = X）完成，并且在任何地方都没有连接（因为 1:1 缓存层）。似乎文档数据库非常适合我的数据。

我试图弄清楚是否有一种方法可以将一个（或多个）对象属性传递给CouchDB map/reduce 函数以在数据库中查找匹配的文档，而无需为每种文档类型创建数十个视图。

是否可以在运行时将所需的文档属性键传递给 CouchDB 并让它返回匹配的对象（或匹配分页的对象的计数）？

例如，在一个页面上，我希望所有带有doc.user_idX 的帖子都是doc.published. 在另一页上，我可能想要所有带有doc.tags[]“运动”标签的文档。

4

3 回答 3

6

您可以构建一个遍历文档中键的视图，并发出一个键[propertyName, propertyValue]- 这样您就可以构建一个包含所有属性/值的单个索引。会很大，不知道如何构建性能以及磁盘使用情况（可能很糟糕）。

地图功能看起来像：

// note - totally untested, my CouchDB fu is rusty
function(doc) {
  for(prop in doc) {
    emit([prop, doc[prop]], null);
  }
}

适用于简单属性的基本情况，并且可以扩展为对数组智能，并为数组中的每个项目发出一个 prop/value 对。那会让你处理标签。

要对其进行查询，请将 [prop] 设置为视图上的查询键。

于 2011-06-28T03:21:24.447 回答
2

基本上，没有。

Couch 和 SQL DB 之类的主要区别在于，在 CouchDB 中进行查询的唯一方法本质上是通过视图/索引。SQL 中的索引是可选的。它们的存在（主要）是为了提高性能。例如，如果您有一个小型数据库，您的应用程序将在索引为 0 的 SQL 上运行良好。（可能是唯一约束的一些问题，但这是一个细节。）

总体而言，SQL 数据库中的查询处理器的一部分包括除了简单的索引之外的其他数据访问方法，特别是表扫描、合并连接等。

Couch 没有查询处理器。它具有用于定义 B-Tree 索引的视图（由 JS 定义）。

而且，就是这样。这就是沙发的锤子。是个好锤子。它已经在数据处理领域持续了 40 年。

在 Couch 中创建索引有点昂贵（基于数据量），这就是为什么“临时视图”不受欢迎的原因。而且它们也有维护成本，因此视图需要成为数据库中的一个有意识的设计元素。同时，它们也比普通的 SQL 索引更强大。

您可以轻松地在 Couch 上添加自己的查询处理，但这对您来说会更有用。您可以根据最流行或最有选择的标准创建一些选择视图，然后在您自己的代码中按其他标准过滤结果文档。是的，您必须这样做，因此您必须质疑所涉及的努力是否比您认为 Couch 通过 SQL 解决方案为您提供的任何好处（HTTP API、复制、安全、始终一致的数据存储等）更有价值。

于 2011-06-28T04:35:06.543 回答
0

我遇到了类似的问题，并使用 CouchDB-Python（这是一个很棒的库）构建了一个快速的解决方法。这不是一个很好的解决方案（违背了 CouchDB 的原则），但它确实有效。

CouchDB-Python 为您提供“查询”功能，它允许您“针对数据库执行临时临时视图”。你可以在这里阅读

我所拥有的是，我将 javascript 函数作为字符串存储在 python 中，并将它与我在 Python 中定义的变量名连接起来。

在 some_function.py

variable = value

# Map function (in javascript)
map_fn = """function(doc) {
     <javascript code>
     var survey_match = """ + variable + """;
     <javascript code>
"""

# Iterates through rows
for row in db.query(map_fn):
     <python code>

它确实不漂亮，并且可能打破了一堆 CouchDB 哲学，但它确实有效。

D

于 2011-06-28T22:44:40.557 回答