我已经对文档数据库特别是CouchDB的简单性感到兴奋。但是我很难理解这样的数据库对于多用户系统是否是可行的选择。由于那些系统需要文档数据库不提供的记录之间的某种关系。

在这种情况下，这完全是错误的工具吗？还是一些标记和临时视图是实现此目的的方法？要不然...

更新：
到目前为止，我已经知道答案了。但是，让我再改一下这个问题。可以说我有大量的半结构化数据，通常适合于CouchDB。我可以将它们标记为" type = post"和" year = 2008"。我的问题是，使用这种标签可以走多远？可以在其中创建包含10.000个名称的数组字段吗？还是有更好的方法来做到这一点？理解如何以这种基于文档的意义进行思考是一个问题。

解决方案

尽管RDBMS是用于大量(尤其是CRUD)应用程序的数据存储/检索的一项常用技术，但多用户系统不需要关系数据库。

如果我们想阅读过去的文档/面向对象的分布式数据库解决方案，请搜索" Lotus Notes / Domino"(这是该领域的一项成熟技术/产品，对在文档中设计应用程序有很好的背景知识。范式。传统上，它非常适合工作流类型的应用程序。

特别是在CouchDB上，签出：

http://wiki.apache.org/couchdb/(这不足为奇)

http://seanoc.wordpress.com/2007/10/12/more-on-couchdb/(易于阅读的描述概述)

http://twit.tv/floss36(有关CouchDB的所有播客访谈)

@micahwittman说什么。快速补充：临时视图绝对不能在生产系统中使用，它们仅用于开发。永久视图可以完成所有临时视图可以完成的工作，而且幅度更大。

不久前，在邮件列表上进行了一次讨论，很适合这个问题。经验法则是仅将数据存储在可能随增长变化的文档中。如果数据更有可能增长，那么我们很可能希望存储单独的文档。

因此，在多用户系统的情况下，一种实现基于ACL的权限的方法可能是创建"权限文档"，该文档将是user_id到doc_id的映射，并标明了适当的权限。

{
    _id: "permission_doc_1",
    type: "acl",
    user: "John",
    docid: "John's Account Info",
    read: true,
    write: true
}

观点将与

function(doc)
{
    emit([doc.user, doc.docid], {"read": doc.read, "write": doc.write});
}

并给定一个docid和userid，检查权限将是：

http://localhost:5984/db/_view/permissions/all?key=["John", "John's Account Info"]

显然，这将需要在客户端和沙发之间进行一些中介，以确保强制执行权限。