每用户数据库（PockDB/couchdb）和；共享数据-可行吗？

我有以下用例/应用程序：

一个TODO应用程序，用户可以：在TODO上CRUD他们的TODO（我使用的是PockDB/couchdb同步）。基本上是根据Josh Morony的

现在，我想添加用户与其他用户“共享”（仅发布，没有“编辑”/“放置”）他们的待办事项的功能，其他用户可以查看（读取）这些待办事项（无写访问权等）

我正在考虑添加一个单独的数据库（我们称之为“共享TODOs数据库”），在这里我的服务器可以写，所有用户只能读。 因此，任何用户都有可能跨该只读数据库执行.find（），而当用户请求共享其TODO时，在该数据库中发布仍将由服务器管理

---

是否有已知的模式（方法）？是否有真正的应用程序/示例已经做到了这一点？

因此，对于此类项目，每个用户的数据库是推荐的数据库模式

主意 因此，基本上，您将有：

• 每个用户一个专用数据库（具有写/读权限）
• 一个中央数据库只读

至于中央数据库，您需要它是只读的，并且还需要只允许共享文档。为此，您需要某种应用程序代理。您基本上可以在中央数据库之上构建一个API，并且只允许访问共享文档

然后，您可以设置从每个用户数据库到中心数据库的复制，并在_replicator数据库中持久化反复制

couchperuser

---

我不确定每个用户的数据库插件目前是否能在2.X.X版本上运行，但您可以通过某种应用程序流程（创建用户，然后创建数据库，然后管理新数据库的权限）来完成这项工作。

CouchDB并没有提供一种很好的方法，但是如果你的后端有一个维护大量共享数据库（除了单用户数据库）的工具，我认为你可以做到

最初的冲动是使用连续过滤复制到/从中央“主”集线器进行复制，但这会给您带来两个问题：

• 复制无法删除文档，除非它们已被删除！即，筛选复制不确定目标中存在哪些文档，而是确定文档的更改是否会传播到目标。这样做的效果是，您可以共享，但不能取消共享
• 这种复制无法扩展。对于需要保持同步的N个用户数据库，对中央数据库的每次更改都会强制所有N个复制独立处理该更改。现在考虑在中央数据库上发生的变化量M几乎与N成正比（即，你拥有的用户越多，这些用户就必须更频繁地处理中央数据库的变化）！（从一个中央集线器到半共享集线器再到单个数据库呈扇形展开），但这也增加了实际的复杂性

您的共享是如何组织的？您可以为每个“共享”组合设置一个共享数据库

当用户A希望与用户B共享文档D时，将文档“移动”到新的数据库AB中。实际上，这意味着：将D的内容复制到数据库AB中的新文档D’，然后从数据库A中删除原始D

这是如何同步的

请记住，数据库客户端可以复制到多个源数据库或从多个源数据库复制，因此用户A将从A和AB复制，而用户B将从B和AB复制。诀窍是在相反方向使用过滤复制，返回到服务器数据库：

现在共享的文档D'不应进入数据库A或数据库B，同样，非共享的文档X也不应进入数据库AB。类似如下：

┌───────────────────────┐                                  
│  server:5984/user_a   │                                  
└───┬───────────────▲───┘                                  
    └─┐           ┌─┘    ┌──────────────────────────────┐  
      │           ●──────│ if (doc.shared_with == null) │  
    ┌─▼───────────┴─┐    └──────────────────────────────┘  
    │     local     │                                      
    └──▲──────────┬─┘                                      
     ┌─┘          └─┐      ┌──────────────────────────────┐
     │              ●──────│ if (doc.shared_with == 'ab') │
 ┌───┴──────────────▼────┐ └──────────────────────────────┘
 │ server:5984/shares_ab │                                 
 └───────────────────────┘              

因此，假设共享数据库已经设置，当本地客户端想要共享某些数据时，它实际上会将

\u deleted:true

添加到原始（非共享）文档中，并创建一个新的（共享）文档。删除的原始文档会传播到服务器上的用户数据库，创建的副本会传播到共享数据库

取消共享的工作原理基本相同：客户端将

\u deleted:true

添加到共享文档中，并在新的非共享副本中重新创建数据。从B的角度看，文档在shares\u ab中出现过，现在由于从shares\u ab中删除而消失

---

（代替用户“配对”，您可以将其扩展到临时用户集，或将其简化为用户已在的特定组，或诸如此类。关键思想是为每个所需的唯一共享上下文创建一个实际共享的数据库。）

您基本上可以设置从用户数据库到中央数据库的复制。中央数据库上的外观将过滤数据，以仅显示可访问的文档（取决于您的权限/共享模式）嘿，Alexis，你让我很感兴趣。但是如果你能详细阐述一下facade的具体内容-你如何在复制目标数据库前面实现facade？我不知道如何组织这样的facade，因为我认为没有中间人？我在Cloudant查阅了文档，所以我猜你指的是过滤函数？比如confI以这样的方式对用户的DBs进行配置：不共享文档不属于复制的一部分？仅过滤共享文档可能会有问题。假设您仅复制“共享”字段为true的文档。如果您决定更改“共享”字段设置为false，它将不会复制到中央数据库，但不会被删除。这就是为什么您应该为中央数据库添加一些mecanism。因此，从技术堆栈角度看，我不明白这是什么机制？您是指服务（如node.js app）它模仿couchdb接口，充当代理，将所需内容传递给实际的中央数据库？不幸的是，设置连续复制