Couchdb 架构：视图还是文档？

Question

我正在尝试通过一个简单的 RSS 阅读器 Web 应用程序来学习 CouchDB。要求是：

• 允许每个用户将 X 个提要导入到他的列表中
• 用户可以为每个提要添加标签

• 为每个提要维护数据库中最近 50 篇文章的列表

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

在阅读了各种指南和Principles for Modeling CouchDB Documents 这是一个很好的相关问题之后，我想它的结构如下：

• 供稿

  • 姓名
  • 上次更新时间

• 文章

  • FeedId
  • 标题
  • 文字

• 用户

  • 身份证
  • Feed：[feed1，feed2]
  • Tags: {funny: [article, article2]} //也许是一个带有#userid #articleid #tagname 的新数据库？

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

我在正确的轨道上吗？您将如何构建它？

Answer 1

您可能已经看到，NoSQL 完全是基于使用场景的妥协。在某些时候，您将不得不编写视图和查询，并且没有一种设计可以适合所有情况。

在您的场景中，您曾说过每个 Feed 将只有最新的 50 篇文章，因此这些文章很快就会变得无关紧要（与它们相关的任何数据也是如此）。因此，如果您将标签存储在 User 模型中，您将不得不更新用户对象 3 次：1 当用户标记文章时，2 当用户删除标签时，3 当文章变得陈旧时删除。 3 是必然的。

最好将标签存储在文章中，以便它们与文章一起被删除。

• 供稿

  • 姓名
  • 上次更新时间

• 文章

  • FeedId
  • 标题
  • 文字
  • 标签：{ "tag-1" : [ "user1", "user2", ... ], "tag2" : [ "user3", "user4", ... ] }

• 用户

  • 身份证
  • Feed：[feed1，feed2]

您可以看到我正在存储按用户分组的标签。如果您认为这有助于处理（根据您的过滤要求），您也可以执行相反的操作 { "user1" : "tag1", "user2" : "tag1", "user3" : "tag2", "user4" : "tag2", ... }。

Answer 2

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

RSS 阅读器模型中的交互实际上使这个问题不太适合 CouchDB。您必须保留每个用户的标签，并且您 (a) 不想将它们保留在用户文档中，因为您必须一直更新用户文档，并且 (b) 不想将它们保留在文章中文档，因为您必须一直更新文章文档。

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