Couchdb體系結構：視圖還是文檔？

Question

我正在嘗試通過一個簡單的RSS閱讀器Web應用程序來學習CouchDB。 要求是：

• 允許每個用戶將X個提要導入其列表
• 用戶可以向每個供稿添加標簽

• 為每個提要維護數據庫中最近50篇文章的列表

• 用戶每次訂閱的任何提要添加新項目時，都應獲得更新。

在閱讀了各種指南和有關CouchDB文檔的建模原理之后，這是一個非常相關的問題，下面是我如何設想其結構：

• 提要

  • 名稱
  • 最近更新時間

• 文章

  • FeedId
  • 標題
  • 文本

• 用戶數

  • ID
  • 供稿：[feed1，feed2]
  • 標簽：{funny：[article，article2]} //也許是一個帶有#userid #articleid #tagname的新數據庫？

然后，對於每個用戶，我將通過feed創建帶有文章的視圖，並向其中添加標簽以在ui中呈現它。

我在正確的軌道上嗎？ 您將如何構成？

Answer 1

我認為您的設計不適合CouchDB。 特別是，因為在我看來，您似乎必須大量更新用戶文檔（主要是更新文章標簽），並且用戶文檔會隨着時間的推移而變得很大。

RSS閱讀器模型中的交互實際上使此問題不太適合CouchDB。 您必須保留每個用戶的標簽，並且（a）不想將其保留在用戶文檔中，因為您必須一直更新用戶文檔，並且（b）不想將其保留在文章中文檔，因為您必須一直更新文章文檔。

我認為理想的解決方案將涉及每個用戶的數據庫。 這將使問題易於解決。 您具有提要文檔和文章文檔，並且可以僅將用戶標簽保留在文章文檔中。 有很多重復項（因為您必須將文章存儲在每個用戶數據庫中），但是至少它很容易（且相對較快）進行查詢。

Answer 2

如您所見，NoSQL完全是基於使用場景的折衷方案。 在某些時候，您將不得不編寫視圖和查詢，並且沒有一種適合所有情況的設計。

在您的場景中，您曾說過每個Feed僅包含最新的50條文章，因此這些文章將很快變得無關緊要（與它們相關的任何數據也將不相關）。 因此，如果將標簽存儲在User模型中，則必須更新用戶對象3次： 1在用戶為文章添加標簽時， 2在用戶刪除標簽時添加， 3在文章過時並被刪除時更新。 3是必然的。

最好將標記存儲在文章中，以便將它們與文章一起刪除。

• 提要

  • 名稱
  • 最近更新時間

• 文章

  • FeedId
  • 標題
  • 文本
  • 標簽：{“ tag-1”：[“ user1”，“ user2”，...]，“ tag2”：[“ user3”，“ user4”，...]}

• 用戶數

  • ID
  • 供稿：[feed1，feed2]

您可以看到我正在存儲按用戶分組的標簽。 如果您認為這有助於處理{ "user1" : "tag1", "user2" : "tag1", "user3" : "tag2", "user4" : "tag2", ... }也可以執行相反的{ "user1" : "tag1", "user2" : "tag1", "user3" : "tag2", "user4" : "tag2", ... } （根據您的過濾要求）。