上回提到，对比关系型数据库的全部，非关系型数据库就像偏科选手。但是非关系型数据库也有全能型选手，那就是mongodb。今天简单说下mongo的基本特征，和它是如何存储数据的。
首先mongodb是文档型数据库，所谓文档型数据库就是数据以json格式进行存储，一个文档数据对象中可以嵌套着另一个对象，可以包含数组（早期数组只允许嵌套两层，后面解除了这个限制，但是还是不建议嵌套太多层，会影响解析数据的性能）。
JSON 数据模型对于开发者来说是比较合适的，在适合用mongo开发的情况下，你会发现代码量比关系型数据库少了挺多，JSON模式简化了数据库层面设计，orm编码的工作
image.png
文档格式类似于上面，对象里面既可以嵌套对象，也可以嵌套数组。
有个说法是mongo是无模式，不需要模型设计的？这是什么意思。
传统模型设计：从概念到逻辑到物理
image.png
即为从一个虚渺的概念->类图->真正数据库的存储数据（包括外键索引等）
而在设计过程中有一个原则是在遵循三大范式的同时,允许适量的冗余。
在这个原则下，一个对象可能被拆成好几张表来进行存储；
而mongo由于是文档型数据库，整个对象可以直接进行存储，所以逻辑模型和物理模型通常是类似的，导致让人有一个错觉。mongo是不需要模型设计的。实际上概念模型到逻辑模型还是需要的。
mongo不要求绝对准守范式，还鼓励着数据的冗余，把大部分有关系的数据存储在同一个文档中，可以很大的提高mongo的性能（这个mongo的索引设计有关）
但是不是所有有关联的数据都可以冗余，mongo的一个文档不能大于16M，而且有些数据需要经常更改，冗余的话，牵一发而动全身，这样的设计是不合理的，因此有些情况还是需要抽取出来成两个文档，通过逻辑外键进行管理（mongo没有物理外键）
那冗余在一个文档中mongo怎么来表现关系型数据库的关联关系：一对一，一对多，多对多？
答案通过内嵌对象或数组；一对一内嵌对象，一对多，多对多通过内嵌数组都可以解决
mongo逻辑外键的话有关联语句吗？
mongo在聚合操作中有一个$lookup 可以来模仿关联查询，但是它的功能相当于left join而已，而且效率没mysql的高，在分片情况下还会失效（可以想象分片相当于mysql中的分表，分表后关联查询也不好查）。
所以本篇得出第一个优缺点：
优点：mongodb可以减少代码的开发量，方便模型设计
缺点：关联关系比较多的业务，不适合使用mongodb做为应用数据库
为什么mongo建议数据尽可能放一个文档，第一个原因是关联不方便，还有一个原因是查询不方便，下一篇就来聊聊mongo的索引
网友评论