前言

MongoDB是一種流行的數(shù)據(jù)庫，可以在不受任何表格schema模式的約束下工作。數(shù)據(jù)以類似JSON的格式存儲，并且可以包含不同類型的數(shù)據(jù)結構。例如，在同一集合collection 中，我們可以擁有以下兩個文檔document：

{
  id: '4',
  name: 'Mark',
  age: '21',
  addresses : [
    { street: '123 Church St', city: 'Miami', cc: 'USA' },
    { street: '123 Mary Av', city: 'Los Angeles', cc: 'USA' }
  ]
}

{
  id: '15',
  name: 'Robin',
  department: 'New Business',
  example: 'robin@example.com'
}

為了能夠充分利用MongoDB的優(yōu)勢，您必須了解并遵循一些基本的數(shù)據(jù)庫設計原則。在講解設計方法之前，我們必須首先了解MongoDB存儲數(shù)據(jù)的結構。

一、 數(shù)據(jù)如何存儲在MongoDB中

與傳統(tǒng)的RDBMS關系型數(shù)據(jù)庫不同，MongoDB并沒有表Table，行row和列column的概念。它將數(shù)據(jù)存儲在集合collections，文檔documents和字段fields中。下圖說明了與RDBMS類比的結構之間的關系：

二、數(shù)據(jù)庫設計技巧和竅門

2.1.規(guī)范化存儲與非規(guī)范化存儲

因為MongoDB使用文檔來存儲數(shù)據(jù)，所以理解“規(guī)范化存儲“”和“非規(guī)范化存儲”的概念非常重要。

規(guī)范化存儲：-規(guī)范化意味著將數(shù)據(jù)存儲到多個集合collections中，并在它們之間設計關聯(lián)關系。數(shù)據(jù)保存之后，更新數(shù)據(jù)比較容易。但是在讀取數(shù)據(jù)的時候，規(guī)范化存儲的缺點就顯現(xiàn)出來。如果要從多個集合collections查找數(shù)據(jù)，則必須執(zhí)行多個查詢，從而使讀取數(shù)據(jù)的速度變慢。 （比如：將網(wǎng)頁標題、作者、內容分別存儲到不同的collections中）

非規(guī)范化存儲：-這種方式將若干對象數(shù)據(jù)，以嵌套的方式存儲到單個文檔中。它在讀取數(shù)據(jù)的時候表現(xiàn)更好，但在寫入時會變慢。這種存儲數(shù)據(jù)的方式還將占用更多空間。 （比如：將網(wǎng)頁標題、作者、內容分別存儲到同一個collection中）

所以在兩種存儲數(shù)據(jù)方式之間進行選擇之前，先評估一下你的應用數(shù)據(jù)庫的使用方式。

如果您有一個不需要頻繁更新的數(shù)據(jù)，更新的即時一致性不是很重要，但是在讀取時需要良好的性能，那么非規(guī)范化可能是明智的選擇。（比如：我們博客的博文，作者一旦保存之后，幾乎就不在進行頻繁的修改，但是面臨著讀者頻繁的讀取閱讀操作）

如果數(shù)據(jù)庫中的文檔數(shù)據(jù)需要不斷的更新，并且您希望在寫入時具有良好的性能，那么您可能需要考慮規(guī)范化存儲。（比如：需要頻繁修改數(shù)據(jù)的業(yè)務類系統(tǒng)）

2.2. 一對多關系

與RDBMS相比，在MongoDB中對“一對多”關系建模需要進行更細粒度的設計。許多初學者陷入將文檔數(shù)組嵌入父文檔中的陷阱。正如我們在上文中介紹的，知道何時進行規(guī)范化存儲或非規(guī)范化存儲是非常重要的。因此設計者需要考慮關系的基數(shù)是“一個對少數(shù)幾個”還是“一個對多個”？每種關系將具有不同的建模方法。

例如：下面“一個對少數(shù)幾個”的建模示例。最好的建模方法是在父文檔（persopn）中嵌入幾個（address）：

> db.person.findOne()
{
 name: 'Mark Kornfield',
 ssn: '1223-234-75554',
 addresses : [
   { street: '123 Church St', city: 'Miami', cc: 'USA' },
   { street: '123 Mary Av', city: 'Los Angeles', cc: 'USA' }
 ]
}

在“一個對多個”示例中，我們將考慮設計兩個集合，即產(chǎn)品products集合和零件parts集合。每個零件都有一個“ ObjectID”，該“ ObjectID”將出現(xiàn)在產(chǎn)品集合的引用中。這樣的設計可以讓讀寫性能更高效。

> db.parts.findOne()
{
  _id : ObjectID('AAAA'),
  partno : '1224-dsdf-2215',
  name : 'bearing',
  price: 2.63

> db.products.findOne()
{
  name : 'car',
  manufacturer : 'Ford',
  catalog_number: 2234,
  parts : [   // array of references to Part documents
    ObjectID('AAAA'),  // reference to the bearing above
    ObjectID('F17C'),  // reference to a different Part
    ObjectID('D2AA'),
    // etc
]

2.3.設計模式可視化

盡管MongoDB是schemaless“無模式的”，但仍然存在將集合collections可視化為圖表的方法。能夠查看設計圖，將對您理解和設計MongoDB的方式上產(chǎn)生重大影響。

DbSchema是可以很好地完成可視化設計工作的一個工具。如下圖所示，它將通過讀取集合和文檔來推導架構。此外，您只需單擊就可以修改圖中的對象。在DbSchema中，您還可以為MongoDB創(chuàng)建外鍵，當然僅在本地創(chuàng)建，只用于設計目的。

2.4.智能索引

為了保持數(shù)據(jù)庫的良好性能，有必要建立智能索引，這將簡化寫入和讀取操作。知道MongoDB的索引優(yōu)勢和局限性非常重要，MongoDB保留用于排序操作的內存限制為32MB。如果你不使用索引，則排序時數(shù)據(jù)庫將被迫將所有排序文檔hold在內存里面，如果達到32M的限制，則數(shù)據(jù)庫將返回錯誤或空集。

結論

對MongoDB的透徹理解與對數(shù)據(jù)庫想要實現(xiàn)的目標的清晰了解是良好數(shù)據(jù)庫設計的秘訣。

總結

到此這篇關于MongoDB設計方法以及技巧的文章就介紹到這了,更多相關MongoDB設計方法及技巧內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！