MongoDB Data Relationship Modeling

The data in MongoDB is very flexible, and the collection does not force the document to adopt a uniform structure. But it is still important to consider the data model seriously, as it affects the performance of the application and the ability of the database. This article describes how to model a pair of one or one-to-many relationship models that are common in MongoDB.

(1) One-to-one embedded document model (Embedded)

Suppose that the sponsor and address are a one-to-one relationship, and the sponsor has a single address. A sponsor can be regarded as a property or field of an address, which can also be regarded as a property or field of a sponsor. In a similar relationship, the advantage of using an embedded data Model (Embedded) is that you get all the data you want in a single query, and the Reference Model (REFERENCES) requires multiple queries to get the data you want (name and address).

relationship between Sponsor and address (References)

{ _ID: "Joe", Name: "Joe bookreader" } { PATRON_ID: "Joe", Street: "123 Fake Street", City: "Faketon", State: "MA", Zip: "12345" }

relationship between Sponsor and address (embeded)

{ _ID: "Joe", Name: "Joe Bookreader", Address: { Street: "123 Fake Street", City: "Faketon", State: "MA", Zip: "12345" } }

(2) One-to-many embedded document model (Embedded)

Assuming that the sponsor and address are a one-to-many relationship, the sponsor has multiple addresses and can use the reference model to treat the sponsor as an attribute of the address, using an embedded model to treat the address as the sponsor's attribute. Such a scenario is suitable for using an embedded model, where you can get all the data you want with a single query dozen. Secondly, in a context can see data data, the structure is relatively simple.

relationship between Sponsor and address (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" }

relationship between Sponsor and address (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" } ] }

(iii) One -to-many-reference document model (References)

Book publishers and Books is a one-to-many relationship, a publication can be the first edition of many books, a book can only be issued by one publisher. In this case, if we still use the embedded data model, it may result in duplication of data, see:

{ Title: "Mongodb:the Definitive Guide", Author: ["Kristina Chodorow", "Mike Dirolf"], Published_date:isodate ("2010-09-24"), pages:216, Language: "中文版", Publisher: { Name: "O ' Reilly Media", founded:1980, Location: "CA" } } { Title: "Tips and Tricks for MongoDB Developer", Author: "Kristina Chodorow", Published_date:isodate ("2011-05-06"), pages:68, Language: "中文版", Publisher: { Name: "O ' Reilly Media", founded:1980, Location: "CA" } }

to avoid duplication of data, the best approach is to use a reference data model to store book publishers and first-edition books in separate collections.

When using a reference model, the reference relationship is stored on which side is determined by the amount of data between the relationships. If publishers ' books grow very slowly, it can be said that the number of books published by each publisher is limited and the relationship can be stored on the publisher's side. As shown below:

{ 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: "中文版" } { _id:234567890, Title: "Tips and Tricks for MongoDB Developer", Author: "Kristina Chodorow", Published_date:isodate ("2011-05-06"), pages:68, Language: "中文版" }

But if publishers have a very large number of books published, this model can lead to changes in the data model, especially in the case of growing arrays. At this point, it is best to store the reference relationship on the book side, such as:

{ p>   _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: "中文版",    publisher_id: "OReilly" } {    _id:234567890,    title: "Tips and Tricks for MongoDB Developer ",    author:" Kristina chodorow ",    published_date: Isodate ("2011-05-06"),    pages:68,    language: "中文版",     publisher_id: "OReilly" }

This article is from the "Dust Wind with the Sky" blog, please be sure to keep this source http://genuinecx.blog.51cto.com/2890523/1547805

MongoDB Data Relationship Modeling