作为一个习惯于用关系术语思考的人，我正试图掌握以“noSQL 方式”思考的问题。
假设以下场景：
我们有一个博客（例如 9gag.com），里面有很多帖子和注册用户。每个用户都可以喜欢每个帖子。我们想建立一个推荐引擎，所以我们需要跟踪：
- 用户查看的所有帖子
- 用户喜欢的所有帖子
帖子有：标题、正文、类别。用户拥有：用户名、密码、电子邮件、其他数据。
在关系数据库中，我们会有类似的东西：posts, users, posts_users_views (post_id, users_id, view_date), posts_users_likes (post_id, user_id, like_date).
问题
在面向文档/列的 noSQL 数据库中，“正确”的结构是什么？
澄清：我们是否应该在用户中保存所有查看/喜欢的帖子 ID 的数组（或帖子中的用户 ID）？如果是这样，我们不会遇到行大小变大的问题吗？
在 CouchDB 中，您可以为用户、帖子、视图等拥有单独的文档。显示用户的视图/喜欢可以通过“视图”（物化映射/减少查询）来安排，映射函数发出数组键[user_id, post_id]。结果，您将获得已排序的字典（按字典顺序按键排序），因此每个视图的所有视图user='ID'都是键从[ID]to开始的查询[ID,{}]。您可以对其进行优化，但基本解决方案非常简单。
在 CouchDB wiki中有一条关于使用关系建模设计和视图整理机制的评论（可以替代一些简单的连接）。为了获得一些直觉，我更建议研究帖子和评论的问题，这也很简单，但没有视图和喜欢那么琐碎:)
可能没有 NoSQL 方式，但我认为大多数 map/reduce 系统都有类似的思维方式。CouchDB 是一个很好的入门工具，因为它非常有限 :) 在分布式环境中很难做任何低效的查询，它的 map 和 reduce 查询功能不会有副作用（它们正在生成物化视图，当文档set 已更改，结果不应取决于文档更新的顺序）。