一  挑战

设计从来就是个挑战。

当我们第一次接触数据库，学习数据库基础理论时，都需要学习范式，老师也一再强调范式是设计的基础。范式是这门课程中的重要部分，在期末考试中也一定是个重要考点。如果我们当年大学挂科了，说不定就是范式这道题没有做好。毕业后，当我们面试时，往往也有关于表设计方面拷问。

很多时候，我们错误地认为，花费大量时间用在设计上，问题根源在于关系数据库(RDBMS)，在于二维表及其之间的联系组成的一个数据组织。而真实的环境中，我们正在大量使用noSQL或者NewSQL，按照目前的趋势（DB-Engines Ranking 得分），将来还会越来越普遍。选用noSQL或者NewSQL 就不需要模式设计了。并且，随着公司、行业数字化程度的加深，智能化触角逐渐延伸，数据量越来越大，结构越来越复杂。 例如现在很火的IOT行业，复杂的业务信息、多样的传输协议、不断升级的传感器，都需要灵活的数据模型来应对。在这种呼唤声中，MongoDB闪亮登场了。MongoDB支持灵活的数据模型。主要体现在以下2点：

（1）自由模式，无需提前声明、创建表结构，即不用先创建表、添加字段，然后才可以Insert数据。默认情况下MongoDB无需这样操作，除非开启了模式验证。

（2）键值类型自由，MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。字段值可以包含其他文档，数组及文档数组。

MongoDB不需要模式设计时错误的，其实面对复杂的结构对象，模式的自由带来更大的挑战。

模式的自由是对数据insert这个动作而言，它去除很多限制了，可以快速讲对象的存进来，并且易于扩展。但是不一定就会带来好的查询性能，好的查询性能还要来自于好的模式设计、来自于好的集合文档的设计。

二  模式设计

MongoDB可以将模式设计划分为内嵌模式（Embedded）和 引用模式（References）

内嵌模式

简单来讲，内嵌模式就是将关联数据，放在一个文档中。例如以下员工信息采用内嵌模式了而存储在了一个文档中：

引用模式

引用模式是将数据存储在不同集合的文档中，而通过关系数据进行关联。例如，这里采用引用模式将员工信息存储在了3个文档中，基本信息一个文档，联系方式一个文档，登录权限放在了一个文档中。每个文档之前通过user_id来关联。

 三  案例 

下面我们通过一些业务场景，一些具体的案例，来分析、品味一下MongoDB模式设计的选择。

案例 1

 假如现在我们描述来顾客（patron）和顾客的地址（address），其ER图如下：

 我们可以将patron和address设计成两个集合(collection,类似于RDBMS数据库中的table)，其具体信息如下：

 patron 集合

{

   _id: "joe",

   name: "Joe Bookreader"

}

 address 集合

{

   patron_id: "joe",

   street: "123 Fake Street",

   city: "Faketon",

   state: "MA",

   zip: "12345"

}

 在设计address 集合时，内嵌了patron集合的_id字段，通过这个字段进行关联。

但这种实体关系为1:1，强关联的关系

推荐设计成如下模式：

{

   _id: "joe",

   name: "Joe Bookreader",

   address: {

              street: "123 Fake Street",

              city: "Faketon",

              state: "MA",

              zip: "12345"

            }

}

 即使用内嵌模式，将数据存储在一个集合中。

案例2

 一个顾客维护一个地址是理想的状况，回头看看我们淘宝账号，就会发现收货地址一般都是2个以上 ( 流泪 ╥╯^╰╥)

 patron 集合顾客joe的文档记录

{

   _id: "joe",