作为一个习惯于以关系术语思考的人，我试图以“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的数组吗？如果是这样，我们不会遇到行大小变大的问题吗？
答案 0 :(得分：0)
在CouchDB中，您可以为用户，帖子，视图等提供单独的文档。显示用户的视图/喜欢可以通过＆＃34; view＆＃34; （物化地图/减少查询），地图函数发出数组键[user_id, post_id]。因此，您将获得已排序的字典（按键按字典顺序排序），因此每user='ID'个视图的所有视图都是从[ID]到[ID,{}]的密钥查询。您可以对其进行优化，但基本解决方案非常简单。
在CouchDB wiki中，有一个关于使用relationally modeled design和view collation机制（可以替换一些简单连接）的评论。为了获得一些直觉，我宁愿建议研究帖子和评论的问题，这也很简单，但不像观点和喜欢那么简单：）
可能没有NoSQL方式，但我认为大多数map / reduce系统都有类似的思维方式。 CouchDB是一个很好的工具，因为它是非常有限的:)在分布式环境中很难做任何低效的查询，它的map和reduce查询函数不会有副作用（它们生成物化视图，在文档时递增） set已更改，结果不应取决于文档更新的顺序。）