MongoDB資料關係建模

標籤：mongodb   資料庫   nosql   資料建模   

    MongoDB中的資料是非常靈活的，集合中也不強制文檔要採用統一的結構。但是認真考慮資料模型依然是非常重要的，因為這會影響到應用程式效能和資料庫的能力。本文講述了MongoDB中常見的一對一、一對多關聯性模型如如何建模。

    （1）一對一嵌入式文檔模型（Embedded Document Model）

  

    假設贊助商和住址是一種一對一關聯性，贊助商只有一處住址。贊助商可以看成是住址的屬性或欄位，住址也可以看成是贊助商的一個屬性或欄位。在類似於這種關係中，使用嵌入式資料模型（Embedded）的好處就是在一次查詢中就能得到想要的全部資料，而引用性模型（References）則需要多次查詢才能得到想要的資料（姓名和住址）。

    贊助商和住址之間的關係（References）

{    _id: "joe",    name: "Joe Bookreader" } {    patron_id: "joe",    street: "123 Fake Street",    city: "Faketon",    state: "MA",    zip: "12345" }

    贊助商和住址之間的關係（Embeded）

{    _id: "joe",    name: "Joe Bookreader",    address: {               street: "123 Fake Street",               city: "Faketon",               state: "MA",               zip: "12345"             } }

    （2）一對多嵌入式文檔模型（Embedded Document Model）

     假設贊助商和住址是一種一對多關聯性，贊助商有多處住址，可以使用引用模型將贊助商當做住址的屬性，可以使用嵌入模型將住址當成贊助商的屬性。這樣的情境適合使用嵌入式模型，一來只有一次查詢就能得到想要的所有資料。二來，在一個上下文中就能看到資料資料，結構比較簡單。

    贊助商和住址之間的關係（References）

{    _id: "joe",    name: "Joe Bookreader" } {    patron_id: "joe",    street: "123 Fake Street",    city: "Faketon",    state: "MA",    zip: "12345" } {    patron_id: "joe",    street: "1 Some Other Street",    city: "Boston",    state: "MA",    zip: "12345" }

     贊助商和住址之間的關係（Embeded）

{    _id: "joe",    name: "Joe Bookreader",    addresses: [                 {                   street: "123 Fake Street",                   city: "Faketon",                   state: "MA",                   zip: "12345"                 },                 {                   street: "1 Some Other Street",                   city: "Boston",                   state: "MA",                   zip: "12345"                 }               ]  }

    （三）一對多引用型文檔模型（References Document Model）

    圖書出版商和圖書之間是一種一對多關聯性，一個出版本可以初版多本圖書，可以一本圖書只能由一個出版商發行。在這種情形下，如果我們仍使用嵌入式資料模型，可能會導致資料重複，見：

{    title: "MongoDB: The Definitive Guide",    author: [ "Kristina Chodorow", "Mike Dirolf" ],    published_date: ISODate("2010-09-24"),    pages: 216,    language: "English",    publisher: {               name: "O‘Reilly Media",               founded: 1980,               location: "CA"             } } {    title: "50 Tips and Tricks for MongoDB Developer",    author: "Kristina Chodorow",    published_date: ISODate("2011-05-06"),    pages: 68,    language: "English",    publisher: {               name: "O‘Reilly Media",               founded: 1980,               location: "CA"             } }

    為了避免出現資料重複，最好的方法是使用引用型資料模型，將圖書出版商和初版圖書分別儲存在不同的集合中。

    使用引用模型時，參考關聯性儲存在哪一方是由關係之間的資料量決定的。如果出版商的圖書增長的非常緩慢，也可以說是每個出版商出版的圖書數量有限，可以將關係儲存在出版商這邊。如下所示：

{    name: "O‘Reilly Media",    founded: 1980,    location: "CA",    books: [12346789, 234567890, ...] } {     _id: 123456789,     title: "MongoDB: The Definitive Guide",     author: [ "Kristina Chodorow", "Mike Dirolf" ],     published_date: ISODate("2010-09-24"),     pages: 216,     language: "English" } {    _id: 234567890,    title: "50 Tips and Tricks for MongoDB Developer",    author: "Kristina Chodorow",    published_date: ISODate("2011-05-06"),    pages: 68,    language: "English" }

    但如果出版商出版的圖書數量非常多，這種模型會導致資料模型發生變化，尤其是增長的數組。這時，最好將參考關聯性儲存在圖書一方，如：

{    _id: "oreilly",    name: "O‘Reilly Media",    founded: 1980,    location: "CA" } {    _id: 123456789,    title: "MongoDB: The Definitive Guide",    author: [ "Kristina Chodorow", "Mike Dirolf" ],    published_date: ISODate("2010-09-24"),    pages: 216,    language: "English",    publisher_id: "oreilly" } {    _id: 234567890,    title: "50 Tips and Tricks for MongoDB Developer",    author: "Kristina Chodorow",    published_date: ISODate("2011-05-06"),    pages: 68,    language: "English",    publisher_id: "oreilly" }

本文出自 “塵風隨影的天空” 部落格，請務必保留此出處http://genuinecx.blog.51cto.com/2890523/1547805

MongoDB資料關係建模