MongoDB是一種流行的資料庫，可以在不受任何表格schema模式的約束下工作。資料以類似JSON的格式儲存，並且可以包含不同型別的資料結構。例如，在同一集合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: '[email protected]' } ~~~ 為了能夠充分利用MongoDB的優勢，您必須瞭解並遵循一些基本的資料庫設計原則。在講解設計方法之前，我們必須首先了解MongoDB儲存資料的結構。 ## 一、 **資料如何儲存在MongoDB中** 與傳統的RDBMS關係型資料庫不同，MongoDB並沒有表Table，行row和列column的概念。它將資料儲存在集合collections，文件documents和欄位fields中。下圖說明了與RDBMS類比的結構之間的關係：  ## 二、**資料庫設計技巧和竅門** ### 2.1.**規範化儲存與非規範化儲存** 因為MongoDB使用文件來儲存資料，所以理解“規範化儲存“”和“非規範化儲存”的概念非常重要。 **規範化儲存**：-規範化意味著將資料儲存到多個集合collections中，並在它們之間設計關聯關係。資料儲存之後，更新資料比較容易。但是在讀取資料的時候，規範化儲存的缺點就顯現出來。如果要從多個集合collections查詢資料，則必須執行多個查詢，從而使讀取資料的速度變慢。 （比如：將網頁標題、作者、內容分別儲存到不同的collections中） **非規範化儲存**：-這種方式將若干物件資料，以巢狀的方式儲存到單個文件中。它在讀取資料的時候表現更好，但在寫入時會變慢。這種儲存資料的方式還將佔用更多空間。 （比如：將網頁標題、作者、內容分別儲存到同一個collection中） 所以在兩種儲存資料方式之間進行選擇之前，先評估一下你的應用資料庫的使用方式。 * 如果您有一個不需要頻繁更新的資料，更新的即時一致性不是很重要，但是在讀取時需要良好的效能，那麼非規範化可能是明智的選擇。（比如：我們部落格的博文，作者一旦儲存之後，幾乎就不在進行頻繁的修改，但是面臨著讀者頻繁的讀取閱讀操作） * 如果資料庫中的文件資料需要不斷的更新，並且您希望在寫入時具有良好的效能，那麼您可能需要考慮規範化儲存。（比如：需要頻繁修改資料的業務類系統） ### 2.2. **一對多關係** 與RDBMS相比，在MongoDB中對“一對多”關係建模需要進行更細粒度的設計。許多初學者陷入將文件陣列嵌入父文件中的陷阱。正如我們在上文中介紹的，知道何時進行規範化儲存或非規範化儲存是非常重要的。因此設計者需要考慮關係的基數是“一個對少數幾個”還是“一個對多個”？每種關係將具有不同的建模方法。  例如：下面“一個對少數幾個”的建模示例。最好的建模方法是在父文件（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' } ] } ~~~ 在“一個對多個”示例中，我們將考慮設計兩個集合，即產品products集合和零件parts集合。每個零件都有一個“ ObjectID”，該“ ObjectID”將出現在產品集合的引用中。這樣的設計可以讓讀寫效能更高效。 ~~~ > 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的方式上產生重大影響。  DbSchema是可以很好地完成視覺化設計工作的一個工具。如下圖所示，它將通過讀取集合和文件來推導架構。此外，您只需單擊就可以修改圖中的物件。在DbSchema中，您還可以為MongoDB建立外來鍵，當然僅在本地建立，只用於設計目的。  ### 2.4.**智慧索引** 為了保持資料庫的良好效能，有必要建立智慧索引，這將簡化寫入和讀取操作。知道MongoDB的索引優勢和侷限性非常重要，MongoDB保留用於排序操作的記憶體限制為32MB。如果你不使用索引，則排序時資料庫將被迫將所有排序文件hold在記憶體裡面，如果達到32M的限制，則資料庫將返回錯誤或空集。  ## **結論** 對MongoDB的透徹理解與對資料庫想要實現的目標的清晰瞭解是良好資料庫設計的祕訣。 ## 歡迎關注我的部落格，裡面有很多精品合集 * 本文轉載註明出處（必須帶連線，不能只轉文字）：[字母哥部落格](http://www.zimug.com)。 **覺得對您有幫助的話，幫我點贊、分享！您的支援是我不竭的創作動力！** 。另外，筆者最近一段時間輸出瞭如下的精品內容，期待您的關注。 * [《手摸手教你學Spring Boot2.0》]( https://www.kancloud.cn/hanxt/springboot2/content ) * [《Spring Security-JWT-OAuth2一本通》](https://www.kancloud.cn/hanxt/springsecurity/content) * [《實戰前後端分離RBAC許可權管理系統》](https://www.kancloud.cn/hanxt/vue-spring/content) * [《實戰SpringCloud微服務從青銅到王者》](https://www.kancloud.cn/hanxt/vue-spring/content) * [《VUE深入淺出系列》](https://www.kancloud.cn/hanxt/vuejs2/