我应该使用单独的集合还是嵌入我知道不会用于所有模型的字段。 MongoDB

Posted 2023-03-11

【中文标题】我应该使用单独的集合还是嵌入我知道不会用于所有模型的字段。 MongoDB

【英文标题】：Should I use separate collection or embed fields that I know won't be used for all models. MongoDB

【发布时间】：2015-03-28 20:55:42

【问题描述】：

背景：

我正在计划一个包含 3 种帖子类型的应用，用于 n 个游戏；单岗位、团队岗位、教练岗位。现在我不确定单个 type 帖子的最佳架构。

某种类型的帖子共享几个基本属性，例如：user_id、cmets、状态等。但与游戏相关的字段将是唯一的。

这是我正在考虑的两种可能性：

1。每个游戏的单独收藏：

如您所见，playerposts 类型需要为每个游戏提供不同的字段，但具有相似的结构。

// game1_playerposts

    _id: ObjectId(),
    user_id: ObjectId(),
    game: ObjectId(),
    comments: [
        user_id: ObjectId(),
        comment: String,
        score: Number
    ],
    rank: 
        name: String,
        abbr: String,
        img: String
    ,
    roles: [String],
    gamemode: [String]


// game2_playerposts

    _id: ObjectId(),
    user_id: ObjectId(),
    game: ObjectId(),
    comments: [
        user_id: ObjectId(),
        comment: String,
        score: Number
    ],
    level: 
        name: String,
        abbr: String,
        img: String
    ,
    champions: [String],
    factions: [
        name: String,
        abbr: String,
        img: String
    ]

2。所有游戏的一个集合：

这样我只需要一个集合，并且总是只使用我需要的字段，其余的将保持为空。

    _id : ObjectId(),
    user_id : ObjectId(),
    game1 : 
        game: ObjectId(),
        rank: 
            name: String,
            abbr: String,
            img: String
        ,
        roles: [String],
        gamemodes: [String]
    ,
    game2 : 
        game: ObjectId(),
        level: 
            name: String,
            abbr: String,
            img: String
        ,
        champions: [String],
        factions: 
            name: String,
            abbr: String,
            img: String
        
    ,
    game_n 
    ...
    ,
    comments : [
        user_id: ObjectId(),
        comment: String,
        score: Number
    ],

什么更好？

这些选项中哪一个更适合？性能很重要，但当我们决定在未来添加对另一款游戏的支持时，我也希望它能够简单地添加到架构中。

【问题讨论】：

MongoDB 是无模式的。我不明白为什么你必须有你知道不会被使用的字段。为什么不为每个单独的玩家帖子创建一个单独的文档，并且该文档将具有与帖子类型相关的架构？我的意思是，您可以在一个集合中包含 “每个游戏的单独集合” 标题下作为示例的两个文档。

@NoOutlet 谢谢，我一直在关注 MEAN 堆栈上的一些教程，所以当大多数教程要求您使用 mongoose.Schema 创建模型时，我想我感到困惑。

好吧，公平地说，我没有使用 Mongoose 并为它定义模式，所以我不知道它在这方面将如何工作。但如果它摆脱了 MongoDB 的无模式特性，那将是使用它的一个相当大的缺点......

看来你已经回答了我的问题。没有理由使用选项 1。就模式而言，我相信我可以为每个写入相同集合的游戏设置几个不同的模式。在我的 API 的某些端点上完成时实际上可能会有所帮助。

【参考方案1】：

MongoDB 是无模式的。

我不明白为什么你必须有你知道不会被使用的字段。为什么不为每个单独的玩家帖子创建一个单独的文档，并且该文档将具有与帖子类型相关的架构？

您可以在一个集合中包含“每个游戏的单独集合”标题下作为示例的两个文档。

我没有使用过 Mongoose，但如果使用它消除了 MongoDB 无模式的好处，我认为它不会像现在这样受欢迎，所以我认为它有一种工作方式。