近些年，No-SQL数据库兴起，在存储与处理大数据方面具备天然的优势。但对于如何设计No-SQL数据库的资料少之又少，很多人都是在边实践、边学习，踩过不少坑。MongoDB是目前主流的No-SQL之一，文档关系的设计是其中常见的难点。本系列文章将从基础谈起，聊聊如何将文档关系设计做好。本文是此系列文章的第一篇，介绍文档关系设计的基础知识。
当开始设计MongoDB的结构（schema）时，你需要考虑一个在SQL关系型数据库（RMDBS）不会遇到的问题：文档之间的数量对应关系。具体来说，你需要思考one-to-N关系是one-to-few，one-to-many或者one-to-squillions三种中的哪种。根据具体的对应关系不同，你将会使用不同的关系模型。
1. 基本模型：One-to-Few
一个one-to-few的例子就是一个人的地址。在这个例子中，地址文档（Address）适合被内嵌（embedded）在人（Person）的文档中，可以将Address文档以数组的方式存储在Person的文档中。
这种设计具有内嵌关系的优点和缺点。优点在于你无须利用一个单独的查询来读取内嵌文档的细节；主要的缺点在于你无法作为一个单独的实体来访问内嵌文档的细节。
在人-地址的例子中，你可以非常方便查询到一个人名下的所有地址，但对于查询所有地址在某个城市的人，将会是相当困难。
2. 基本模型：One-to-Many
一个典型one-to-many的例子就是电商系统中的顾客与订单之间的关系，而且随着时间的增加，顾客的订单数会逐渐增长，会达到上百，甚至上万个。在这种情形下，非常适合使用引用（reference），将订单的ObjectIDs存储在一个数组中，然后内嵌在顾客的文档中。
在这种设计中，每个订单是一个文档，每个顾客也是一个文档，而且包含一个指向订单引用的数组。那么为了获取某个顾客的所有订单，可以通过应用程序层面（application-level）的关联操作来实现。为了提高查询效率，需要对顾客的_id建立索引。由于orders._id本身就存在索引（因为_id存储在一个数组中），所以对订单的查询效率通常很高。
这种内嵌文档引用的方式既有好处，也有坏处。由于每个子文档（订单）是一个独立的文档，因而对于搜索与更新子文档（订单）来说，非常方便。但这种设计的一个不足之处在于，需要两个查询才能获得子文档（订单）的详情。比如要查询名为张三顾客的未付款订单详情：第一步，根据姓名查询顾客集合，获取顾客张三的文档；第二步，根据查的顾客文档，再查询所有未付款订单详情。
这种设计的一个额外好处，就是可以拓展到N-to-N关系模型，由于子文档是独立存在的文档，那么子文档可以内嵌在多个不同的父文档中。比如在一个学校中，学生与老师之间是一个N-to-N关系，老师可以给多名学生授课，一名学生可以拥有多名授课老师。
3. 基本模型：One-to-Squillions
这是一对超多的关系，这个超多的概念可以理解为千万级别的数据量。一个常见的例子就是应用的日志系统，日志系统收集分布式主机上的各种事件日志，这个数据非常大，而且增长迅速。即使采用日志文档引用数组的方式进行存储，任何一台主机上的日志数量可以很容易超过16MB的文档大小。此时，非常适合采用常见的父引用（parent-referencing）方式进行存储：每台主机拥有一个文档，然后将主机日志文档的引用存储在日志消息的文档中。
在此种情形下，你可以利用应用程序级别上的关联查询，来获取某个主机上的最近5000条日志。
说明：对于BSON-document方式存储的文件，其大小的限制是16MB，如果希望存储更大数据大小的集合文件，可以考虑GridFS方式。更多关于GridFS的说明，可以参考官方文档。
总结
以上是三种基本的one-to-N关系模型，当你设计MongoDB的数据库结构时，你需要考虑两个因素：
- 对于N类文档，是否需要单独被存储？
- 文档之间的具体关系是什么，是one-to-few，one-to-many，还是one-to-sequillions？
基于这两方面的因素，你可以选择上述三种的一种方式进行设计：
- 如果是one-to-few关系，并且无须从父文档之外的方式访问N类文档，内嵌N类文档；
- 如果是one-to-many关系，并且希望N类文档以独立的文档存储，那么使用N类文档的引用数组，并内嵌在父文档中；
- 如果是one-to-sequillions关系，在N类文档中存储一个指向one类文档的引用。
N类文档，代表处在N这边的文档，在一个顾客订单（one-to-many）关系中，N类文档指订单文档，one类文档代指顾客文档
如果觉得此文能够给你带来帮助和启发，请不要吝啬你的赞_。同时关注该该专题，后面的章节会陆续奉献给大家。祝各位周末愉快！
