在MongoDB的數據有靈活的模式。不像SQL數據庫，（SQL數據庫）要求你必須在插入數據之前決定和聲明一個表的模式，MongoDB的集合不強制文檔的結構。這個靈活性有利於文檔到實體或對象的映射。每個文檔可以匹配所要表示實體的數據字段，即使數據的變化很顯著。但在實際操作中，一個集合的文檔共享一個相似的結構。
數據模型的關鍵挑戰在於平衡應用的需要，數據庫引擎的性能和數據存取模式。當設計數據模型時，要考慮數據在應用裏的使用情況（如，查詢、更新和處理數據），以及數據本身的內在結構。
文檔結構
在爲MongoDB應用設計數據模型時的關鍵是圍繞文檔的結構和應用時如何表示數據間的聯繫。有兩個工具來允許應用來表示這些關係：引用和嵌入文檔( references and embedded documents)。
- 引用
引用通過包括連接或一個文檔到另一個文檔間的引用存儲着數據間的關係。應用能夠解析這些引用來訪問到相關數據。廣義上說，這些都是歸一化的數據模型(normalized data models).
上圖的數據模型使用引用來聯繫文檔。contract文檔和access文檔都保護着user文檔的引用。
下面介紹歸一化數據模型在使用引用的優缺點：
歸一化模型使用引用描述文檔間的關係。一般地，使用歸一化模型的情況有，
- 當嵌入會導致數據重複且不會提供有效的讀性能。
- 表示更復雜的多對多的關係
- 對大型分級數據建模
引用比嵌入式文檔的靈活性更大。但客戶端應用必須處理引用帶來的查詢問題。總之，歸一化數據模型需要更多的往返服務器。
- 嵌入數據
嵌入式文檔通過在一個單一文檔結構裏存儲相關數據來捕獲數據間的關係。MongoDB的文檔使在一個文檔裏的一個字段或字段數據嵌入一個文檔作爲子文檔具體可能性。這些非規範化數據使得應用可以在一個單一數據庫操作力獲取和操縱數據。
上圖的數據模型就是嵌入式字段保護所有的相關信息。
下面討論嵌入子文檔的數據模型的優缺點：
使用MongoDB，你可以在一個單一結構或文檔嵌入相關數據。這個模型是著名的“非規範化”模型，利用了MongoDB豐富文檔的優勢。
嵌入數據模型允許應用在相同的數據庫記錄裏存儲相關片段信息。因此，應用在完成一個常規操作時，只需處理很少的查詢或更新。
一般，當下面情形時可使用嵌入數據模型：
- 實體間有“包含關係”
- 實體間有一對多的關係。在這些關係裏，“多“或子文檔經常被看做"一"或父文檔的上下文裏
一般來說，嵌入提供了更好的讀性能，以及在單一數據庫操作裏請求和獲取相關數據的能力。嵌入數據模型使得在哪一個原子操作裏更新相關數據成爲可能。
然而，在一個文檔的嵌入數據模型可能導致文檔創建後的增長。文檔的增長會影響寫性能並導致數據碎片問題。並且，在MongoDB裏的文檔大小必須小於最大的BSON文檔大小。對大型二進制數據，考慮GridFS。
寫操作的原子性
在MongoDB，寫操作在文檔這一級是原子的，並且沒有單一的寫操作能原子性的影響多個文檔或集合。一個有嵌入數據的非規範化數據模型在一個單一文檔裏包含了能表示一個實體的相關數據。這有利於寫操作的原子性，因爲單一的寫操作能直接對一個實體插入或更新數據。規範化數據會在多個集合裏分散了數據，這會要求多次寫操作，因此不是原子性的。
然而，有利於原子性寫的模式會限制一個應用使用數據的方法或修改數據的方法。因此需要平衡原子性和平衡性。
文檔增長
有的更新，比如向數組添加元素或添加新的字段，會增大文檔的大小。如果文檔的大小超過了給該文檔分配的空間，MongoDB會重新定位這個文檔。文檔的增長會影響規範化和非規範化數據的選擇。
數據使用和性能
當設計一個文檔模型，要考慮應用將如何使用你的數據庫。比如，如果你的應用僅使用最近插入的數據，考慮使用 Capped Collections.或者，你的應用需要總是讀操作，添加索引是常見的提升性能的辦法。
