持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第12天，点击查看活动详情
数据建模是我们在开发过程中一项很重要的能力，数据建模最具挑战性的是在需求、性能和数据读写模式之间做权衡考量。当建模的时候，一定要考虑应用程序对数据的使用模式（如查询，更新和处理）以及数据本身的天然结构。
MongoDB 的数据模式是一种 灵活模式 。关系型数据库要求你在插入数据之前必须先定义好一个表的模式结构，而MongoDB的集合则并不限制文档结构。这种灵活性让对象和数据库文档之间的映射变得很容易。 即使数据记录之间有很大的变化，每个文档也可以很好的映射到各条不同的记录。 当然在实际使用中，同一个集合中的文档往往都有一个比较类似的结构。
文档结构
设计基于MongoDB的应用程序的数据模型时的关键就是选择合适的文档结构以及确定应用程序如何描述数据之间的关系。
有两种方式可以用来描述这些关系： 引用和内嵌。
Embedded Data - 内嵌
内嵌方式指的是把相关的数据保存在同一个文档结构之内。MongoDB 允许一个字段或者一个数组作为一个内嵌文，这些非规范的数据模型可以让我们完成对数据的查询和修改。
对于MongoDB中的许多情况，大部分都是以内嵌形式，而且也是官方比较推荐的。
References - 引用
引用方式通过存储链接或者引用来存储数据之间的关系。我们可以通过获取这些引用来访问数据。其实就是和我们关系型的主外键关系差不多。从广义上讲，这些是标准化数据模型。
对比
查询
从查询效率上来讲，引用相比于内嵌还是比较慢的.
引用虽然提供了lookup和DBRef的操作，但是性能还是不能和直接查询出来做比较。
写操作的原子性
写入操作在单文档是原子操作，即使该操作修改了单个文档中的多个内嵌文档。所以使用内嵌文档有助于原子操作。
内嵌文档也有一定限制，因为单条文档有大小限制，我们也不能让文档无限制的增长。
还有一些文档的更新操作，例如：在数组里增加元素或者增加一个新字段， 会导致文档的大小变大。如果文档的大小超出分配给文档的原空间大小， 那么MongoDB就需要把文档从磁盘上的现有位置移动到一个新的位置以存放更多的数据。
使用和性能
设计文档模型时，一定要考虑应用程序会如何使用你的数据。例如，假如你的应用程序通常只会使用最近插入的文档，那么可以考虑使用限制集。或者如果你的应用会做大量的读操作，那么可以通过加多一些索引的方法来提升常见查询的性能。
