2

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

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

  • 对于每个提要维护数据库中最后 50 篇文章的列表

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

在阅读了各种指南和CouchDB 文档建模原则（这是一个很好的相关问题）之后，我认为它的结构如下：

  • 饲料

    • 姓名
    • 最近更新时间

  • 文章

    • FeedId
    • 标题
    • 文本

  • 用户

    • ID
    • 饲料：[饲料1，饲料2]
    • 标签： {funny: [article, article2]} //也许是一个带有#userid #articleid #tagname 的新数据库？

然后对于每个用户，我会通过提要创建一个包含文章的视图，并将标签添加到它以在 ui 中呈现它。

我在正确的轨道上吗？你会如何构建这个？

4

2 回答 2

0

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

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

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

于 2013-05-16T10:38:35.727 回答
0

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

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

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

  • 饲料

    • 姓名
    • 最近更新时间

  • 文章

    • FeedId
    • 标题
    • 文本
    • 标签：{“tag-1”：[“user1”，“user2”，...]，“tag2”：[“user3”，“user4”，...]}

  • 用户

    • ID
    • 饲料：[饲料1，饲料2]

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

于 2013-05-21T21:29:01.883 回答