MongoDB Schema 设计建议

Posted 2023-03-11

【中文标题】MongoDB Schema 设计建议

【英文标题】：MongoDB Schema Design suggestion

【发布时间】：2017-08-29 21:43:57

【问题描述】：

我使用 MongoDB 已经有一段时间了，但我只在其他人已经完成了设计模式的基本任务时才使用它来执行 CRUD 操作。所以，基本上这是我第一次设计模式，我需要一些建议。 我将从用户那里收集的数据是他们的常规信息、健康相关信息和保险相关信息。单个用户不会拥有多个健康和保险相关信息，因此它是简单的一对一关系。但是这些健康和保险相关的信息将有很多领域。所以我的问题是。单独收集健康和保险相关信息是否很好：

     var userSchema = 
              name : String,
              age  : Number,
    health_details :  [ type: Schema.Types.ObjectId, ref: 'Health' ],//reference to healthSchema
 insurance_details :  [ type: Schema.Types.ObjectId, ref: 'Insurance' ] //reference to insuranceSchema    
     

或拥有一个包含大量字段的集合：

     var userSchema = 
              name : String,
              age  : Number,
          disease_name : String, // and many other fields related to health
          insurance_company_name : String //and many other fields related to insurance
     

【参考方案1】：

一般来说，在 NoSql 中建模 1 对 1、1 对多和多对多数据时可以考虑的一些因素是：

1.数据重复

您希望数据重复吗？这也不是像爱好“园艺”这样的单字方式，许多用户可以拥有并且可能不需要“爱好”收藏，而是像作者和书籍这样的东西。这种情况保证重复。

一个作者可以写很多本书。即使在两本书中，您也不应该嵌入作者。当作者信息发生变化时，很难维护。使用一对多。并且参考可以放在两个文件中的任何一个中。作为“有很多”（作者中的 bookId 数组）或“属于”（每本书中的 authorId）。

在健康和保险的情况下，由于数据不会重复，因此单个文档是更好的选择。

2。读/写偏好

读取和写入数据（不是收集）的预期频率是多少？例如，您查询用户、他的健康和保险记录比更新它更频繁（如果 1 和 3 不是什么大问题），那么这些数据最好包含在单个文档中并从单个文档中查询，而不是三个不同的来源.

此外，Mongodb 保证一个文档的原子性，如果您想同时更新用户、健康和保险（比如在一个 API 中），这将是一个额外的好处。

3。文档大小

考虑一下：很多用户可以喜欢一个帖子，而一个用户可以喜欢很多帖子（多对多）。由于您需要确保没有用户两次点赞帖子，因此用户 ID 必须存储在某处。三个可用选项：

在发布文档中保留用户 ID 数组 在用户文档中保留帖子 ID 数组 创建另一个包含两者 id 的文档（仅适用于多对多的解决方案，类似于 SQL）

如果帖子被超过 100 万用户点赞，则帖子文档将充满用户参考。同样，用户可以在短时间内点赞数千条帖子，因此第二种选择也不可行。这给我们留下了第三种选择，这是最适合这种情况的选择。

但一个帖子可以有多个 cmets，而一条评论只属于一个帖子（一对多）。现在，您几乎不会期望超过几百个。难得一千。因此，在 post 中保留一个 commentId 数组（或嵌入的 cmets 本身）是一种实用的解决方案。

在您的情况下，我不相信没有大量引用列表的文档可以增长到足以达到 16 MB（Mongo 文档大小限制）。因此，您可以将健康和保险数据安全地存储在用户文档中。但他们应该有自己的钥匙，例如：

 var userSchema = 
          name : String,
          age  : Number,
          health : 
             disease_name : String,
             //more health information
          ,
          insurance :
             company_name : String,
             //further insurance data
          
 

在我看来，这就是您在设计架构时应该考虑的方式。我建议阅读 Couchbase 提供的这些非常有用的数据建模指南：Document design considerations、modeling documents for retrieval 和 modeling relationships。虽然与 Couchbase 相关，但这些规则同样适用于 mongodb 模式设计，因为它们都是 NoSql 和面向文档的数据库。