一 挑战
设计从来就是个挑战。
当我们第一次接触数据库，学习数据库基础理论时，都需要学习范式，老师也一再强调范式是设计的基础。范式是这门课程中的重要部分，在期末考试中也一定是个重要考点。如果我们当年大学挂科了，说不定就是范式这道题没有做好。毕业后，当我们面试时，往往也有关于表设计方面拷问。
很多时候，我们错误地认为，花费大量时间用在设计上，问题根源在于关系数据库(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",
name: "Joe Bookreader"
}
address 集合joe顾客的地址1的文档记录
{
patron_id: "joe",
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
}
address 集合中joe顾客的地址2的文档记录
{
patron_id: "joe",
street: "1 Some Other Street",
city: "Boston",
state: "MA",
zip: "12345"
}
像这种1：N的关系，并且N可以预见不是很多的情况下，我们推荐采用内嵌模式，
将集合文档设计成如下模式：
{
_id: "joe",
name: "Joe Bookreader",
addresses: [
{
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
},
{
street: "1 Some Other Street",
city: "Boston",
state: "MA",
zip: "12345"
}
]
}
与案例1的不同就是地址信息采用了数组类型，数组的字段值又为内嵌子文档。
案例3
上面介绍的是1对多的关系（1：N），但是N值不是很大。但是现实世界中，有时候会遇到N值比较大的情况。
比如 出版社和书籍的关系，一个出版社可能已将出版了成千上万本书籍了。
其设计模式可以如下（内嵌模式），将出版社的信息作为一个子文档，来内嵌到书籍的文档中，具体信息如下：
以下书籍《MongoDB: The Definitive Guide》的文档信息：
{
title: "MongoDB: The Definitive Guide",
author: [ "Kristina Chodorow", "Mike Dirolf" ],
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English",
publisher: {
name: "O'Reilly Media",
founded: 1980,
location: "CA"
}
}
以下书籍《50 Tips and Tricks for MongoDB Developer》的文档信息：
{
title: "50 Tips and Tricks for MongoDB Developer",
author: "Kristina Chodorow",
published_date: ISODate("2011-05-06"),
pages: 68,
language: "English",
publisher: {
name: "O'Reilly Media",
founded: 1980,
location: "CA"
}
}
从中可以看出，publisher信息描述比较多，并且都相同，每个文档中都存放，浪费太多的存储空间，显得无用臃肿，还有个明显的缺点就是 当publisher数据更新时，需要对所有的书籍文档进行刷新。理所当然地，就会想到将出版社独立出来，单独设计一个文档。（引用模式）。
引用模式1
我们可以这样设计：出版社单独设计为一个集合文档（文档中引用书籍的编号），如下：
{
name: "O'Reilly Media",
founded: 1980,
location: "CA",
books: [123456789, 234567890, ...]
}
书籍集合中编号为123456789的书籍的文档：
{
_id: 123456789,
title: "MongoDB: The Definitive Guide",
author: [ "Kristina Chodorow", "Mike Dirolf" ],
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English"
}
书籍集合中编号为234567890的书籍的文档：
{
_id: 234567890,
title: "50 Tips and Tricks for MongoDB Developer",
author: "Kristina Chodorow",
published_date: ISODate("2011-05-06"),
pages: 68,
language: "English"
}
此设计中，将出版社出版的书的编号，保存在了出版社这个集合中。
但是这种设计还是有问题，例如，数组的更新、删除相对比较困难。还有就是，每增加一个书籍集合的文档，同时还要修改这个出版社结合的文档。 所以，我们还可以将这种集合文档设计优化如下。
引用模式2
此时出版社的文档记录如下：（不再应用书籍文档的编号）
{
_id: "oreilly",
name: "O'Reilly Media",
founded: 1980,
location: "CA"
}
此时书籍的文档记录如下：（书籍为123456789，文档引用了出版社的_ID）
{
_id: 123456789,
title: "MongoDB: The Definitive Guide",
author: [ "Kristina Chodorow", "Mike Dirolf" ],
published_date: ISODate("2010-09-24"),
pages: 216,
language: "English",
publisher_id: "oreilly"
}
此时书籍的文档记录如下：（书籍为234567890，文档引用了出版社的_ID）
{
_id: 234567890,
title: "50 Tips and Tricks for MongoDB Developer",
author: "Kristina Chodorow",
published_date: ISODate("2011-05-06"),
pages: 68,
language: "English",
publisher_id: "oreilly"
}
案例 4
上面三个例子，在关系型数据库中都可以用我们学习过的关系（例如1：1；1：N）来描述，那么我们再举一个关系型数据库难以描述的关系 -- 树状关系。
例如，我们在电商网站上常见的商品分类关系，一级商品、二级商品、三级商品、四级商品关系。我们简化此例子如下：
那么在MongoDB中可以轻松实现他们关系的查询。
情景1 查询节点的父节点（或称为查询上一级分类）；或者查询节点的子节点（或者为查询下一级分类）
文档的设计为：
db.categories.insert( { _id: "MongoDB", parent: "Databases" } )
db.categories.insert( { _id: "dbm", parent: "Databases" } )
db.categories.insert( { _id: "Databases", parent: "Programming" } )
db.categories.insert( { _id: "Languages", parent: "Programming" } )
db.categories.insert( { _id: "Programming", parent: "Books" } )
db.categories.insert( { _id: "Books", parent: null } )
查询节点的父节点（或称为查询上一级分类）的语句，例如查询MongoDB所属分类：
db.categories.findOne( { _id: "MongoDB" } ).parent
查询节点的子节点（或者为查询下一级分类），例如查询Database的直连的子节点（不是孙子节点）。
db.categories.find( { parent: "Databases" } )
上面的文档可以查询出子文档，但是会显示出多个文档，例如上面的查询语句，会返回出MongoDB 文档和 dbm文档 ，我们还需要还特殊处理，那么可不可以在一个文档中显示出所以的子节点呢？
可以的。文档模式设计如下：
db.categories.insert( { _id: "MongoDB", children: [] } )
db.categories.insert( { _id: "dbm", children: [] } )
db.categories.insert( { _id: "Databases", children: [ "MongoDB", "dbm" ] } )
db.categories.insert( { _id: "Languages", children: [] } )
db.categories.insert( { _id: "Programming", children: [ "Databases", "Languages" ] } )
db.categories.insert( { _id: "Books", children: [ "Programming" ] } )
如果这时候查询Databases的子节点，就会是一个文档了。查询验证语句如下：
db.categories.findOne( { _id: "Databases" } ).children
此模式也支持查询节点的父节点。例如查询MongoDB这个节点的父节点：
db.categories.find( { children: "MongoDB" } )
情景2 查询祖先节点
其文档设计为：
db.categories.insert( { _id: "MongoDB", ancestors: [ "Books", "Programming", "Databases" ], parent: "Databases" } )
db.categories.insert( { _id: "dbm", ancestors: [ "Books", "Programming", "Databases" ], parent: "Databases" } )
db.categories.insert( { _id: "Databases", ancestors: [ "Books", "Programming" ], parent: "Programming" } )
db.categories.insert( { _id: "Languages", ancestors: [ "Books", "Programming" ], parent: "Programming" } )
db.categories.insert( { _id: "Programming", ancestors: [ "Books" ], parent: "Books" } )
db.categories.insert( { _id: "Books", ancestors: [ ], parent: null } )
例如查询MongoDB节点的祖先节点：
db.categories.findOne( { _id: "MongoDB" } ).ancestors
当然也可以查询 后代节点：
db.categories.find( { ancestors: "Programming" } )
四 后记
MongoDB的模式设计是一个比较大的课题，需要多看看情景案例，多品味一些优秀的文档设计，多问些问什么要这样做，是否有更优的设计，要慢慢去领悟MongoDB的哲学思想。
总之，这是一个多看、多想、多思的蜕变羽化过程，可能时间很长、过程有些痛苦。
本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！
本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！