上回提到，對比關(guān)系型數(shù)據(jù)庫的全部靡菇，非關(guān)系型數(shù)據(jù)庫就像偏科選手重归。但是非關(guān)系型數(shù)據(jù)庫也有全能型選手，那就是mongodb厦凤。今天簡單說下mongo的基本特征鼻吮，和它是如何存儲數(shù)據(jù)的。
首先mongodb是文檔型數(shù)據(jù)庫较鼓，所謂文檔型數(shù)據(jù)庫就是數(shù)據(jù)以json格式進(jìn)行存儲狈网，一個文檔數(shù)據(jù)對象中可以嵌套著另一個對象，可以包含數(shù)組（早期數(shù)組只允許嵌套兩層笨腥，后面解除了這個限制拓哺，但是還是不建議嵌套太多層，會影響解析數(shù)據(jù)的性能）脖母。
JSON 數(shù)據(jù)模型對于開發(fā)者來說是比較合適的士鸥，在適合用mongo開發(fā)的情況下，你會發(fā)現(xiàn)代碼量比關(guān)系型數(shù)據(jù)庫少了挺多谆级，JSON模式簡化了數(shù)據(jù)庫層面設(shè)計(jì)烤礁，orm編碼的工作
文檔格式類似于上面，對象里面既可以嵌套對象肥照，也可以嵌套數(shù)組脚仔。
有個說法是mongo是無模式，不需要模型設(shè)計(jì)的舆绎？這是什么意思鲤脏。
傳統(tǒng)模型設(shè)計(jì)：從概念到邏輯到物理
即為從一個虛渺的概念->類圖->真正數(shù)據(jù)庫的存儲數(shù)據(jù)（包括外鍵索引等）
而在設(shè)計(jì)過程中有一個原則是在遵循三大范式的同時,允許適量的冗余。
在這個原則下吕朵，一個對象可能被拆成好幾張表來進(jìn)行存儲猎醇；
而mongo由于是文檔型數(shù)據(jù)庫，整個對象可以直接進(jìn)行存儲努溃，所以邏輯模型和物理模型通常是類似的硫嘶，導(dǎo)致讓人有一個錯覺。mongo是不需要模型設(shè)計(jì)的梧税。實(shí)際上概念模型到邏輯模型還是需要的沦疾。
mongo不要求絕對準(zhǔn)守范式，還鼓勵著數(shù)據(jù)的冗余第队，把大部分有關(guān)系的數(shù)據(jù)存儲在同一個文檔中哮塞，可以很大的提高mongo的性能（這個mongo的索引設(shè)計(jì)有關(guān)）
但是不是所有有關(guān)聯(lián)的數(shù)據(jù)都可以冗余，mongo的一個文檔不能大于16M斥铺，而且有些數(shù)據(jù)需要經(jīng)常更改彻桃，冗余的話，牽一發(fā)而動全身晾蜘，這樣的設(shè)計(jì)是不合理的邻眷，因此有些情況還是需要抽取出來成兩個文檔眠屎，通過邏輯外鍵進(jìn)行管理（mongo沒有物理外鍵）
那冗余在一個文檔中mongo怎么來表現(xiàn)關(guān)系型數(shù)據(jù)庫的關(guān)聯(lián)關(guān)系：一對一，一對多肆饶，多對多改衩？
答案通過內(nèi)嵌對象或數(shù)組；一對一內(nèi)嵌對象驯镊，一對多葫督，多對多通過內(nèi)嵌數(shù)組都可以解決
mongo邏輯外鍵的話有關(guān)聯(lián)語句嗎？
mongo在聚合操作中有一個$lookup 可以來模仿關(guān)聯(lián)查詢板惑，但是它的功能相當(dāng)于left join而已橄镜，而且效率沒mysql的高，在分片情況下還會失效（可以想象分片相當(dāng)于mysql中的分表冯乘，分表后關(guān)聯(lián)查詢也不好查）洽胶。
所以本篇得出第一個優(yōu)缺點(diǎn)：
優(yōu)點(diǎn)：mongodb可以減少代碼的開發(fā)量，方便模型設(shè)計(jì)
缺點(diǎn)：關(guān)聯(lián)關(guān)系比較多的業(yè)務(wù)裆馒，不適合使用mongodb做為應(yīng)用數(shù)據(jù)庫
為什么mongo建議數(shù)據(jù)盡可能放一個文檔姊氓，第一個原因是關(guān)聯(lián)不方便喷好，還有一個原因是查詢不方便翔横，下一篇就來聊聊mongo的索引
