PouchDb/CouchDb中的递归删除？

Question

我正在实现一个应用程序，使用PouchDB同步到云上的CouchDB。我有一个递归的类别层次结构。

服装

• 顶上

- Shirts  
    - T-shirts
    - Dress shirts

​

- Jackets  
    - Bombers
    - Motorcycle

​

​

• 底座

- Pants
- Shorts

​

我存储它的方式是使用“类别”类型，并且每个类别都有一个"parentId“--没有父节点的是根节点。这样，我想父母就像一种外键。

首先，我不知道这是否是正确的存储方式，但它似乎在我的应用程序工作得很好。问题是，当我想删除时，我应该做什么？例如，如果我想删除"Tops“-我必须递归遍历树并对每个项执行删除吗？这真的是正确的方法吗？似乎与同步，它将是非常“聊天”，在上述情况下，我将不得不触发类似于3个查询和4个删除？

请指点我

Answer 1

您似乎已经将关系数据模型映射到文档存储中。

除非有很好的理由不这样做，否则我建议使用一个“库存”文档，其中包含您正在讨论的所有存储在其中的信息？那么你说的删除应该是这样的：

db.get('inventory').then(function(doc) {
  delete doc.tops
  return db.put(doc);
}).then...etc

在OP的评论之后更新

大多数人都是这样做的，他们以非常理性的DB心态对待文档存储。我建议两种不同的心态转变：

1. 想象一下文档存储更像是将程序中的对象保存在RAM中，并将它们按原样保存到磁盘上。
2. 将默认设置为“我所有数据的一个文档”，并且只有在有理由的情况下才创建一个单独的文档。

创建多份文件可能还有其他原因，但对我来说，主要的两个原因是：

1. 唯一性:文档的_id是CouchDB中唯一能为您提供系统范围(或真正的DB范围)机制/检查/约束的东西。所以像用户这样的东西，有了独特的用户名，我就把自己的文档放进去了。
2. 避免冲突:如果有多个客户端更新相同的数据，例如。客户订单进入您的系统，，特别是多个节点的相互复制。把事情分开，这样并发写就不会发生在同一个文档上了，这样你的生活就容易多了。

除了这些原因之外，我建议将所有内容保留在一个文档中，然后创建有意义的视图，以便只获取所需的数据。

因此，对于你的具体后续问题：

你是说有一个医生来托管整棵树吗？

是的，正如我上面所说，我建议有一个单一的“库存”文件。

这是存储这类数据的常见方法吗？

我不知道有多普遍/不常见，我知道很多人犯了你犯的错误，并以关系的心态接近文档存储，所以这可能是相当普遍的。但是，这不是一种好的方法，而且会导致许多麻烦，因为文档存储没有RDBMS的相同特性，例如。缺少用于多个文档更新的事务。

这种做法有什么坏处吗？

除了我上面提到的独特性和矛盾之外，没有。

如果我有“衬衫1"，我希望它属于上衣/衬衫/t恤，所以需要某种身份证明。

想想你是如何在内存中做到这一点的。

例如：与您所想的结构不同，您可能会使用以下文档结构：

{
  "_id": "inventory",
  "skus": {
    "123456": {
      "sku": "123456",
      "name": "Purple T-Shirt",
      "tags": [ "top", "t-shirt", "shirt", "purple" ]
    },

    # ...
}

然后在视图中，您将通过标记生成对数据的查找，例如：

function(doc) {
  if(doc._id == "inventory") {
    for(var sku in doc.skus) {
      var item = doc.skus[sku]
      item.tags.forEach( function(tag) { emit( tag, sku ) })
    }
  }
}

因此，您可以使用该视图查找任何您想要的sku，然后使用：doc.items[sku]检索它。或者，如果您希望索引中包含该数据，则可以将该项放入emit输出中。