Database Couchdb体系结构：视图还是文档？

我试图通过一个简单的RSS阅读器web应用程序学习CouchDB。这些要求是：

• 允许每个用户将X个提要导入其列表
• 用户可以向每个提要添加标记
• 对于每个提要，维护数据库中最后50篇文章的列表

• 每当用户订阅的任何提要向其中添加新项目时，都应该得到更新

在阅读了各种指南之后，这是一个非常相关的问题，下面是我对其结构的设想：

• 喂养
  • 名字
  • 最后更新
• 文章
  • FeedId
  • 头衔
  • 正文
• 使用者
  • 身份证
  • 提要：[提要1，提要2]
  • 标签：{有趣：[article，article2]}//可能是一个带有#userid#articleid#标记名的新数据库

然后，我会为每个用户创建一个包含文章的视图，并在其中添加标签，以便在ui中显示文章

---

我走对了吗？您将如何构建此功能？

我认为您的设计不太适合CouchDB。特别是，因为在我看来，您需要大量更新用户文档（主要是更新文章标签），并且用户文档会随着时间的推移而变得非常庞大

RSS阅读器模型中的交互实际上使这个问题不太适合CouchDB。您必须保留每个用户的标记，并且您（a）不希望将它们保留在用户文档中，因为您必须始终更新用户文档；以及（b）不希望将它们保留在文章文档中，因为您必须始终更新文章文档

---

我认为我的理想解决方案将涉及每个用户的数据库；这将使问题变得容易处理。您有提要文档和文章文档，您只需将用户标记保留在文章文档中即可。有很多重复（因为您必须在每个用户数据库中存储文章），但至少查询起来很容易（而且相对快速）。

正如您可能看到的，NoSQL完全是基于使用场景的折衷方案。在某些时候，您将不得不编写视图和查询，并且没有一种设计适合所有人

在您的场景中，您已经说过每个提要将只包含最新的50篇文章，因此这些文章很快就会变得无关紧要（与它们相关的任何数据也是如此）。因此，如果将标记存储在用户模型中，则必须更新用户对象三次：

1

当用户标记文章时，

2

当用户删除标记时，以及

3

当文章过时并被删除时<代码>3是不可避免的

最好将标签存储在文章中，这样它们就会随着文章一起被删除

• 喂养
  • 名字
  • 最后更新
• 文章
  • FeedId
  • 头衔
  • 正文
  • 标记：{“tag-1”：[“user1”、“user2”，…]，“tag2”：[“user3”、“user4”，…]}
• 使用者
  • 身份证
  • 提要：[提要1，提要2]

---

您可以看到，我正在存储按用户分组的标记。如果您认为这有助于处理（基于您的过滤要求），您也可以执行相反的

{“user1”：“tag1”，“user2”：“tag1”，“user3”：“tag2”，“user4”：“tag2”，…}

.

如果您不介意压缩数据库并丢失修订历史记录，我认为多次更新CouchDB文档并不一定是一件坏事。它确实存在文档冲突的可能性，解决文档冲突很烦人。我认为每个用户的数据库在这方面做得太过分了。每个提要50篇文章，并假设平均每个用户订阅10篇提要。那是500篇文章。如果文章是按feed_id进行索引/分区的，那么查询起来就相对便宜。哦，我想我的重点是针对每个用户重复的文章文档。