MongoDB中的数据有一个灵活的模式。不像SQL数据库，你必须确定在插入数据之前和声明一个表的模式，

MongoDB的集合不执行文档结构。他灵活便利的映射文件一个实体或对象。每个文档可以匹配的数据字段代表的实体,

即使数据有实质性的变化。然而在实践中,集合中的文件共享一个相似的结构。数据建模的关键挑战是平衡应用程序

的需要,数据库引擎的性能特征,数据检索模式。在设计数据模型时,总是考虑应用程序使用的数据(如查询、更新和处

理的数据)以及数据本身固有的结构。

文档结构

    MongoDB应用程序的数据模型设计的关键决定因素是：围绕文档的结构以及应用程序表示数据之间的关系。有两

个工具,允许应用程序表示这些关系:引用和嵌入的文档。

引用

    引用引用存储关系数据,包括链接或引用从一个文档移到另一个地方。应用程序可以解决这些引用访问相关数

据。广泛地说,这些都是规范化数据模型（描述使用引用文档之间的关系。）

    使用条件：（1）当可读性能的优势，大于数据重复时（2）表示复杂的多对多关系时（3）大型分层数据集进行建模。

嵌入式

在一个文档或者数组。这些非规范化数据模型允许应用程序检索和操作相关的数据在一个单一的数据库操作。简单说

就是：MongoDB,你可以将相关数据嵌入到一个结构或文档。这些模式通常被称为“非正规”模型,并利用MongoDB的丰

富的文档。不用考虑表结构，嵌入式数据模型允许应用程序相关的信息存储在同一个数据库记录。结果是,应用程序

可能需要完成常用操作问题更少的查询和更新。如下图：

    使用条件（1）一对一的关系模型（2）一对多的关系模型

    一般而言,嵌入为读操作提供了更好的性能,以及能够在单个数据库操作请求和检索相关数据。嵌入式数据模型能

够更新相关数据在一个单一的原子写操作。然而,在文档中嵌入相关数据可能导致文件创建后的增长情况。文档增长

可影响写性能的影响,导致数据碎片。此外,MongoDB文档必须小于最大BSON文档大小。对于大部分二进制数据,请考虑

GridFS.

写操作的原子性

    在MongoDB文档级别的写操作是原子的,没有一个写操作可以自动影响多个文档或多个集合。规范化数据模型与嵌

入式数据结合了所有相关的数据代表的实体在一个文档。这有助于原子写操作从一个写操作可以插入或更新数据实

体。然而,写操作的原子可能会限制应用程序可以使用数据的方式也可能限制修改应用程序的方法。

数据使用和性能

MongoDB数据模型