Question

我正在研究mongodb并希望为网络博客页面构建一个小数据库。众所周知，在mongo中，我们使用表和记录相反的集合和文档。

我有2个文件（实体）：用户（id，nikname）和Publication（id，title ...）在关系数据库中，我们将user_id作为“Publication”中的列，这意味着用户可以有很多出版物。

示例1

User 
{
  id: "123456",
  nikname: "cool guy",
  publications: [   
        {
            id: "some id1",
            title: "some title111",
            text: "bla bla bla",
            // any fields
        },
        {
            id: "some id2",
            title: "some title222",
            text: "bla bla bla",
            // any fields
        },
        ....
    ]
}

Publication 
{
    id: "some id",
    title: "some title",
    text: "bla bla bla",
    // any fields       
}

在上面的示例中，每个用户都有自己的出版物数组。

我的问题是：这是一个很好的方法吗？如果一个用户有1000个出版物怎么办？

此外，如果每个用户都有自己的出版物，那么为什么我们需要存储出版物表（在MONGO中称为COLLECTION）在用户之外作为单独的实体。

我还在考虑在用户内部存储发布ID。

例2

User 
{
  id: "123456",
  nikname: "cool guy"
}

Publication 1
{
    id: "some id",
    title: "some title",
    text: "bla bla bla",
    // any fields   

    USER_ID: 123456 
} 

Publication 2
{
    id: "some id",
    title: "some title",
    text: "bla bla bla",
    // any fields

    USER_ID: 123456     
}

但是 Example2 与关系方法没有区别......

那么哪种方式会更好？

简而言之，想知道与mongo合作的人的意见。

Answer 1

在Mongo中，您可以通过3种方式设计模型关系。

一对一
一对多（嵌入式文档）：您的示例1
一对多（文献参考）：你的例子2

经验法则是您需要考虑数据检索模式你的申请。

例如，如果您的应用程序需要大量获取与特定用户相关的发布，您可以使用示例1，并且您不需要在单独的集合中维护发布（除非应用程序需要它）。只要单个文档不超过硬限制，就有很多子文档不是问题。

如果您的应用程序需要按出版物和用户进行查询（类似于关系模型），则可以使用示例2。但是我发现这不是一个优化的解决方案。

一些资源： https://docs.mongodb.com/manual/applications/data-models-relationships/

如何在MongoDB中存储数据（文档）

1 个答案: