CouchDB简单文档设计:需要反馈

CouchDB简单文档设计:需要反馈,couchdb,pouchdb,Couchdb,Pouchdb,我正在为CouchDB设计文档存储,非常感谢您的反馈。这些文件代表“资产”。 这些数据库也将通过数据库本地同步到浏览器 要求: 每个用户可以有许多资产 用户可以通过向其他人提供URI(如(xyz.com/some_id)与他们共享资产。一旦用户单击此URI,他们将被视为已“加入”,并且现在是组的一部分 组用户可以与组中的其他成员共享自己的资产 我的设计 每个用户都有自己的数据库来存储资产——我们称之为“用户”。每个用户数据库将以其唯一ID作为前缀 共享资产将存储在一个单独的数据库中——我们

我正在为CouchDB设计文档存储,非常感谢您的反馈。这些文件代表“资产”。 这些数据库也将通过数据库本地同步到浏览器

要求:

  • 每个用户可以有许多资产
  • 用户可以通过向其他人提供URI(如(xyz.com/some_id)与他们共享资产。一旦用户单击此URI,他们将被视为已“加入”,并且现在是组的一部分
  • 组用户可以与组中的其他成员共享自己的资产
我的设计

  • 每个用户都有自己的数据库来存储资产——我们称之为“用户”。每个用户数据库将以其唯一ID作为前缀
  • 共享资产将存储在一个单独的数据库中——我们称之为“组”。共享资产在此处重复,并有一个附加的userId字段(表示创建者)
  • 组数据库以唯一ID作为前缀,就像用户数据库也以唯一ID作为前缀一样
将组资产存储在单独的数据库中的原因是,当PockDB在本地运行时,它只知道当前用户及其共享资产。它不知道其他用户,也不应该查询这些“其他”用户的数据库


如有任何意见,将不胜感激

看起来是个很棒的设计。另一种选择是,每个组(“角色”)只有一个数据库,然后从用户的组复制到其本地数据库中

但是,当需要复制回服务器时,这可能会变得棘手,因为您必须在文档离开用户的本地数据库时对其进行过滤,这取决于它们所属的组数据库。尽管如此,您仍然必须在服务器端使用当前的设计来实现这一点


老实说,两种方法都可以。当前方法的唯一缺点是在服务器端复制文档(每个用户数据库一次,每个组数据库一次)。另一方面,您的客户机代码变得非常简单,因为您不必执行任何过滤复制。如果您的服务器上有足够的空间不用担心,那么我肯定会支持您的方法。:)

谢谢你,诺兰,谢谢你的反馈。谢谢你主动回答我的问题。没问题。很乐意帮忙。:)