mongodb 文档模型

MongoDB文档模型设计的三个误区

• 不需要模型设计
• MongoDB应该用一个超级大文档来组织所有数据
• MongoDB不支持关联或者事务

关于JSON文档模型设计

• 文档模型设计处于物理模型设计阶段（PDM）
• JSON文档模型通过内嵌数组或引用字段来表示关系
• 文档模型设计不遵从第三范式，允许冗余
• 文档模型的设计原则：性能和易用

为什么人们都说MongoDB是无模式？

• 可以省略物理建模的具体过程。

关系模型 vs 文档模型

MongoDB文档模型设计三步曲

1-1关系建模

• 基本原则：一对一关系以内嵌为主，作为子文档形式或者直接在顶级不涉及到数据冗余
• 例外情况：如果内嵌后导致文档大小超过16mb。

1-N关系建模

• 基本原则：一对多关系同样以内嵌为主，用数组来表示一对多，不涉及到数据冗余
• 例外情况：内嵌后导致文档大小超过16mb，数组长度太大，或数组长度不确定等

N-N关系建模

• 基本原则：不需要中间表，一般用内嵌数组来表示一对多，通过冗余来实现多对多
• 例外情况：内嵌后导致文档大小超过16mb，数组长度太大，或数组长度不确定等

根据读写工况细化

• 对于分表的情况，用id或者唯一键进行关联后，可以使用$lookup来提供一次查询多表的能力（类似于mysql join）。

什么时候该使用引用模式？

• 内嵌文档太大
• 内嵌文档或数组元素会频繁修改
• 内嵌数组元素会持续增长并且没有封顶

MongoDB引用设计的限制

• MongoDB对使用引用的集合之间并无主外键检查
• MongoDB使用聚合框架的$lookup来模仿关联查询，只支持left join，且关联目标不能是分片表

分桶模式