MongoDB資料模型

標籤：mongodb   文檔   索引   資料庫   嵌入式   

    MongoDB中的資料有一個靈活的模式。不像SQL資料庫，你必須確定在插入資料之前和聲明一個表的模式，

MongoDB的集合不執行文檔結構。他靈活便利的對應檔一個實體或對象。每個文檔可以匹配的資料欄位代表的實體,

即使資料有實質性的變化。然而在實踐中,集合中的檔案分享權限設定一個相似的結構。資料建模的關鍵挑戰是平衡應用程式

的需要,資料庫引擎的效能特徵,資料檢索模式。在設計資料模型時,總是考慮應用程式使用的資料(如查詢、更新和處

理的資料)以及資料本身固有的結構。

文檔結構

    MongoDB應用程式的資料模型設計的關鍵決定因素是：圍繞文檔的結構以及應用程式表示資料之間的關係。有兩

個工具,允許應用程式表示這些關係:引用和嵌入的文檔。

引用

    引用引用儲存關係資料,包括連結或引用從一個文檔移到另一個地方。應用程式可以解決這些引用訪問相關數

據。廣泛地說,這些都是正常化資料模型（描述使用引用文檔之間的關係。）

    使用條件：（1）當可讀效能的優勢，大於資料重複時（2）表示複雜的多對多關係時（3）大型分層資料集進行建模。

嵌入式
    嵌入式儲存相關資料捕捉資料之間的關係的檔案在一個文檔結構。MongoDB文檔可以嵌入文檔結構的子文檔欄位

在一個文檔或者數組。這些非正常化資料模型允許應用程式檢索和操作相關的資料在一個單一的資料庫操作。簡單說

就是：MongoDB,你可以將相關資料嵌入到一個結構或文檔。這些模式通常被稱為“非正規”模型,並利用MongoDB的豐

富的文檔。不用考慮表結構，嵌入式資料模型允許應用程式相關的資訊儲存在同一個資料庫記錄。結果是,應用程式

可能需要完成常用操作問題更少的查詢和更新。如：

    使用條件（1）一對一的關聯式模式（2）一對多的關聯式模式

    一般而言,嵌入為讀操作提供了更好的效能,以及能夠在單個資料庫操作請求和檢索相關資料。嵌入式資料模型能

夠更新相關資料在一個單一的原子寫操作。然而,在文檔中嵌入相關資料可能導致檔案建立後的增長情況。文檔增長

可影響寫效能的影響,導致資料片段。此外,MongoDB文檔必須小於最大BSON文檔大小。對於大部分位元據,請考慮

GridFS.

寫操作的原子性

    在MongoDB文檔層級的寫操作是原子的,沒有一個寫操作可以自動影響多個文檔或多個集合。正常化資料模型與嵌

入式資料結合了所有相關的資料代表的實體在一個文檔。這有助於原子寫操作從一個寫操作可以插入或更新資料實

體。然而,寫操作的原子可能會限制應用程式可以使用資料的方式也可能限制修改應用程式的方法。

資料使用和效能
    如果應用程式的需求主要是讀取操作集合,添加索引支援常見的查詢可以提高效能。

MongoDB資料模型