查询时的数据局限性
如果你同时需要文档中所有内容，把文档顺序存储，访问效率比较高。
但是如果你只需要访问文档中的某些字段，则文档仍需要将文档全部加载出。但是运用这种局限性不局限于文档型数据库。不同的数据库，会针对不同场景，调整数据物理分布以适用常用访问模式的局限性。
- Spanner 中允许表被声明为嵌入到父表中——常用关联内嵌（获得类似文档模型的结构）
- HBase 和 Cassandra 使用列族来聚集数据——分析型
- 图数据库中，将点和出边存在一个机器上——图遍历
关系型和文档型的融合
- MySQL 和 PostgreSQL 开始支持 JSON 原生支持 JSON 可以理解为，MySQL 可以理解 JSON 类型。如 Date 这种复杂格式一样，可以让某个字段为 JSON 类型、可以修改 Join 字段的某个属性、可以在 Json 字段中某个属性建立索引。
- RethinkDB 在查询中支持 relational-link Joins
科德（Codd）：nonsimple domains，记录中的值除了简单类型（数字、字符串），还可以一个嵌套关系（表）。这很像 SQL 对 XML、JSON 的支持。
总结
当创建逻辑比较复杂，是一个大工程的时候，考虑使用工厂模式，封装对象的创建过程，将对象的创建和使用分离。
什么情况是创建逻辑比较复杂呢？
类似规则配置解析的例子，代码里存在if-else判断，动态的根据不同的类型创建不同的对象。
单个对象本身的创建过程比较复杂，比如要组合其他类对象，做各种初始化操作。
对于情况1，当每个对象的创建逻辑都比较简单，推荐使用简单工厂模式，将多个对象的创建逻辑放到一个工厂类里，当每个对象的创建逻辑都比较复杂的时候，为了避免设计一个庞大的简单工厂类，推荐使用工厂方法模式，将创建逻辑拆分的更细，每个对象的创建逻辑独立到各自的工厂类里。
对于情况2， 因为单个对象本身的创建逻辑比较复杂，推荐使用工厂方法模式。
对于其他情况，如果创建对象的逻辑并不复杂，直接通过new来创建对象就可以了，不需要使用工厂模式。
现在，我们上升一个思维层面来看工厂模式，它的作用无外乎下面这四个。这也是判断要不要使用工厂模式的最本质的参考标准。
封装变化： 创建逻辑有可能变化，封装成工厂类之后，创建逻辑的变更对调用者透明。
代码复用： 创建代码抽离到独立的工厂类之后可以复用。
隔离复杂性： 封装复杂的创建逻辑，调用者无需了解如何创建对象。
控制复杂度： 将创建代码抽离出来，让原本的函数或类职责更单一，代码更简洁。
