1

我正在为我的网站做一个通知系统。类似的通知系统facebook。或stackoverflow。我有2个问题。

  1. 如何存储在数据库中？我可以将所有通知存储在用户文档中吗？或者在一个单独的文档中（因为我认为monogdb在文档中的大小是有限的？）或者，智能存储？（使用 inc 或 db 中的值（参见：true/false），查询复杂）

  2. 页面上的 for 怎么办？例如，当我单击我inbox的 for中的链接时stackoverflow，我将重定向到该页面。但是我，我有一个系统，multipage例如：我有 100 个朋友。每页列出 30 个。因此，当我单击通知时，我无法重定向到，因为不可能知道好的页面（可以删除用户）。

非常感谢你 ！如果您有其他想法，请告诉我。谢谢。

编辑：

（对不起我的英语，我是法国人）

对于第一个问题，我意识到我必须等待时机来选择我的结构。因为我的通知..有点复杂，所以提前感受下。

第二，我解决了这个问题。我解释一下：（我以朋友为例，因为它很容易理解。）我这样存储我的数据：

{
  friends: [
    {_id: xxxxx, ts: xxxx},
    {_id: xxxxx, ts: xxxx}
  ]
}

想象一下，我显示所有朋友：每页 30 个。问题是：

  • 当我想显示所有朋友时，我无法使用 mongo 进行排序。（一个小问题）
  • 如果我想在一个特别的朋友处将用户引导到此列表（每页 30 个），请始终保留sortby ts。我不知道页面。唯一的解决方案是获取所有文档。但是：性能非常差。

所以，我这样存储：

{
  friends: {
    xxxx: {ts:xxx},
    xxxx: {ts:xxx}
  }
}

知道我可以使用跳过和限制对文档进行排序。所以如果我想要一份，我不需要拿走所有的文件。

要知道页面，我只需对 ts 进行 < 或 > 的数量，例如，我有 11 个朋友 > 到我想要的朋友的 ts，并对所有朋友进行计数（例如：50 个朋友）用 50 和 11，我可以猜到页面。

这个解决方案好吗？- 我需要一个计数 - 一个查询以了解 > 或 < 的数量，我可以获取列出朋友的页面，保持the sort ts

你无法理解我为什么使用计数。我需要，因为它们没有存储在同一个文档中。

2 编辑：

query object这个解决方案的问题是我需要update object在mongo query（例如：for dofriends.xxxxxx: {$exists:true}

ps：用什么优势ts代替datemongodb ？我正在使用ts，但我想我会存储date，没有ts。

3 编辑

我会喜欢的Sammaye。存放在单独的文件中。看看： http: //mongly.com/Multiple-Collections-Versus-Embedded-Documents/#1和http://openmymind.net/2012/1/30/MongoDB-Embedded-Documents-vs-Multiple-收藏/

4

2 回答 2

3

@Stennie 给出了一个非常完整的答案。

但是最近我在 PHP 中为我的网站做了类似的事情。首先要了解的是您是在做通知系统还是墙（两者非常不同），我似乎不清楚，我不确定您的意思是：

页面上的 for 怎么办？例如，当我在收件箱中单击 stackoverflow 的链接时，我将重定向到该页面。但是我，例如，我有一个多页面系统：我有 100 个朋友。每页列出 30 个。因此，当我单击通知时，我无法重定向到，因为不可能知道好的页面（可以删除用户）。

那不是很好的英语，当我阅读时非常混乱。如果您可以对此进行扩展，我相信人们可以更好地回答。

对于通知系统，我发现大量通知对象也可以工作。所以我有一个像这样的模式：

{
    _id: {},
    to_user: ObjectId{},
    user_id: ObjectId{}, // Originating user
    custom_text: "has posted a new comment on your wall post",
    read: false,
    ts: MongoDate()
}

这实际上就是我必须生成通知的文件。每次用户提交生成通知的操作时，它都会向数据库写入一个新行，to_user每次都需要通知每个用户。至于执行相同操作的多个用户，我实际上将user_id字段转换为OjbectId's 列表，所以我可以说：

Sam, Dan and Mike all commented on your wall post

然后，我通过ts存储ts用户在他们的行中查看的最后一次进行查询，从而允许我每次对最新通知进行基于范围的查询。根据我的个人经验，这对于分片和查询非常有效。

希望能帮助到你，

于 2012-08-07T13:33:44.060 回答
1

是嵌入还是链接是MongoDB中数据建模的一个常见问题。如果您的通知数量将不受限制，您可能会更好地将它们保存在单独的集合中。

当前的 16Mb 文档限制实际上并不像其他一些考虑那么严重：

  • 通过将所有通知包含在单个文档中可能会遇到的性能问题是快速增长的文档可能还需要更频繁地在数据库中重新定位（请参阅填充因子）。

  • 您可能希望在很短的时间内对文档应用多个更新（例如在通知上设置“读取”标志），这意味着更新同一文档时会出现更多争用（请参阅原子操作）。

为了实现分页，您可以将limit()与范围查询或skip()结合使用。范围查询（例如，基于 indexed notificationDate）将更有效地使用索引，并且比skip()您的集合增长时执行得更好。

于 2012-08-07T02:20:20.817 回答