具有共享/ like / commentfunction的社交网站的mongodb模式？

我正在开发一个社交网站，用户可以在其他function中发布状态，分享/喜欢/评论他人的post。 我正在使用mongodb + nodejs，我遇到了是embedded还是引用用于存储这些数据的文档的问题。

我有一个名为“活动”的集合，它存储用户执行的所有活动，例如share / post / like / comment，以及指定用户执行的活动types的“type”字段。 如果我执行“评论”操作，应该如何存储这些信息？ 我希望发表评论的用户也将该post分享给他/她的朋友，以便他们可以看到评论和post。 我是否应该复制与“用户共享”相同的内容并将其embedded到一个types为“share”的新文档中，还是应该只存储对该内容的引用？

示意图，我应该这样做：

1. embedded：

   var activity = new Schema({ type:String // specifies the type of activity content: [{ // the object that user share/like/comments on. }] }); 

要么

2.referencing：

 var activity = new Schema({ type:String // in this case would be "share", content_id: Schema.Types.ObjectId // the id of the thing I share. }); 

使用embedded方法，被embedded的“已评论”内容将不包含最新的评论，因为它是原始的和任何新的评论共享后将被更新的重复。

使用引用的方法，我有很多困难检索这些结果没有一个混乱的callback（因为一些对象引用也引用其他对象像职位将引用注释）。

在我的情况下，最好的做法是什么？

Answer 1

杰里米

您可能想回答以下几个问题，以便更好地了解您将来如何最终使用这些数据。 通过这些问题的一些问题也将引导您进入schemedevise的特定方向：

1. 用户的活动types是否有限制？ 即这里的主要意图是确定一个非常活跃的用户是否将达到16MB的文档大小限制。 如果是这样，embedded一个活动数组可能没有帮助。

2. 这些logging（活动数组）将在未来被索引/查询吗？ 即这里的意图是通过导致重定位和索引更新的文档大小的变化来识别缓慢/繁重的更新（添加新的活动）。 随着用户的活动数组大小的增长，由于需要维护的索引条目数量，性能会逐渐下降。

3. 从用户的angular度来看这些活动的使用情况如何，这些都是同时查看，还是分页。 如果分页，则可以复制主文档中最近的“N”个活动条目的活动，而其他分开存储。

我还build议查看http://docs.mongodb.org/ecosystem/use-cases/storing-comments/中定义的用户意见。

希望能帮助你做出长期为你服务的决定。