本文更新于2021-12-11，使用MongoDB 4.4.5。
目录- 范式化与反范式化
- 优化数据操作
- 一致性管理
- 模式迁移
范式化与反范式化
范式化（normalization）将数据分散到多个集合，不同集合之间相互引用数据。反范式化（denormalization）将每个文档所需数据都嵌入文档内部。
一个集合中包含的对其他集合的引用数量叫基数（cardinality）。常见的关系有一对一、一对多、多对多。
内嵌数据与引用数据的比较：
| 更适合内嵌 | 更适合引用 |
|---|---|
| 数据较小 | 数据较大 |
| 数据不会定期改变 | 数据经常改变 |
| 最终数据一致即可 | 中间阶段的数据必须一致 |
| 文档数据小幅增加 | 文档数据大幅增加 |
| 数据通常需要执行二次查询才能获得 | 数据通常不包含在结果中 |
| 快速读取 | 快速写入 |
| 基数较少 | 基数较多 |
也可以混合使用内嵌数据和引用数据：创建一个内嵌文档用于保存常用信息，需要查询更详细信息时通过引用找到实际的文档。
优化数据操作
更新数据时，需要明确是否会导致文档体积增长，以及增长程度。如果文档中有字段需要增长，应尽可能将这个字段放在文档最后的位置。
有三种常见的方式用于删除旧数据：使用固定集合，使用TTL集合，使用多个集合并定期删除集合。
一致性管理
服务器为每个数据库连接维护一个请求队列，一个连接拥有一个一致的数据库视图，总时可以读取到这个连接最新写入的数据。
模式迁移
随着需求的变化，数据库模式可能需要相应地改变，不管使用以下哪种方法，都要小心保存应用程序使用过的每一个模式：
- 确保应用程序能支持所有旧版的模式。这种方式可能导致混乱，尤其是不同版本的模式之间有冲突时。
- 在每个文档中包含一个类似“version”的字段，使用这个字段来决定应用程序接受的文档结构。这仍然需要支持各种旧版本。
- 当模式发生变化时将数据进行迁移。通常来说这不是个好主意：MongoDB允许使用动态模式，以避免执行迁移，因为迁移会对系统造成很大的压力。
原文地址：https://www.cnblogs.com/garvenc/archive/2022/02/23/mongodb_learning_application_design.html
