CouchDB是否在运行时按任何文档属性映射/减少？

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

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

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

---

例如，在一个页面上，我希望所有发布了

doc.user\u id

的文章都是

doc.published

。在另一个页面上，我可能希望所有带有

doc.tags[]

和标记“sport”的文档。

您可以构建一个视图，该视图迭代文档中的键，并发出一个

[propertyName，propertyValue]

键，这样您就可以构建一个包含所有属性/值的索引。将是巨大的，不知道性能将如何构建，以及磁盘使用率（可能很差）

映射函数的外观如下所示：

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

适用于简单属性的基本情况，可以扩展为对数组的智能化，并为数组中的每个项发出一个属性/值对。这样你就可以处理标签了

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

基本上，否

coach和sqldb之间的关键区别在于，在CouchDB中查询的唯一方法本质上是通过视图/索引。SQL中的索引是可选的。它们的存在（主要）是为了提高性能。例如，如果你有一个小数据库，你的应用程序将在索引为0的SQL上正常运行。（可能是一些具有唯一约束的问题，但这只是一个细节。）

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

coach没有查询处理器。它有用于定义B树索引的视图（由JS定义）

就这样。那是沙发的锤子。这是一把好锤子。它在数据处理领域已经持续了40年

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

---

您可以随时在coach上添加自己的查询处理，但这对您来说将是更多的工作。您可以根据最常用或最有选择性的条件创建一些选择视图，然后在您自己的代码中按其他条件过滤生成的文档。是的，你必须这样做，因此你必须质疑，所涉及的努力是否比你认为Coach通过SQL解决方案为你提供的好处（HTTP API、复制、安全、始终一致的数据存储等）更有价值。

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

CouchDB-Python为您提供了函数“Query”，它允许您“针对数据库执行临时视图”

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

在某个函数中

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>

变量=值
#映射函数（在javascript中）
map_fn=“”功能（doc）{
var调查_match=“”+变量+”；
"""
#遍历行
对于db.query（map\u fn）中的行：

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

---

D

“始终一致的数据存储”-CouchDB最终不是一致的吗？这意味着它不可能始终一致，因为否则它就不会在CAP定理方面具有高可用性？如果你谈论的是复制和集群，那么它们是一致的。我所说的始终一致的意思是，对于一个单一的沙发，它是一致的“防撞"。即使系统或服务器崩溃，数据库始终处于一致、可用的状态。重新启动后，数据库立即保持一致和可用。因此，听起来这是个坏主意。这是可能的，但却是个坏主意。糟糕的是，多亏了我的ORM，我已经不用编写SQL查询太久了，所以我并不期待编写模型方法ds（或CouchDB中的视图），用于查找数据的所有不同方式。然后，对于项目新手，至少所有查询都列在_设计文档中。