MongoDB Data Link Modeling

MongoDB Data Link Modeling

The data in MongoDB is very flexible, and the collection does not require a uniform structure for documents. However, seriously considering the data model is still very important, because it will affect application performance and database capabilities. This article describes common one-to-one and one-to-many relationship models in MongoDB, such as how to build models.

CentOS compilation and installation of MongoDB

CentOS compilation and installation of php extensions for MongoDB and mongoDB

CentOS 6 install MongoDB and server configuration using yum

Install MongoDB2.4.3 in Ubuntu 13.04

MongoDB beginners must read (both concepts and practices)

MongoDB authoritative Guide (The Definitive Guide) in English [PDF]

(1) One-to-one Embedded Document Model (Embedded Document Model)

Assume that the sponsor and address are in a one-to-one relationship, and the sponsor only has one address. The sponsor can be viewed as an attribute or field of the address, or as an attribute or field of the sponsor. In a relationship similar to this, the advantage of using the Embedded data model (Embedded) is that you can get all the data you want in one query, and the Reference Model (References) you need to perform multiple queries to obtain the desired data (name and address ).

Relationship between sponsors and addresses (References)

{

_ Id: "joe ",

Name: "Joe Bookreader"

}

{

Patron_id: "joe ",

Street: "123 Fake Street ",

City: "Faketon ",

State: "MA ",

Zip: "12345"

}

Relationship between sponsors and addresses (Embeded)

{

_ Id: "joe ",

Name: "Joe Bookreader ",

Address :{

Street: "123 Fake Street ",

City: "Faketon ",

State: "MA ",

Zip: "12345"

}

}

(2) One-to-multiple Embedded Document Model (Embedded Document Model)

Assume that the sponsor and address are in a one-to-multiple relationship. The sponsor has multiple addresses. You can use the reference model to attribute the sponsor as the address, and use the embedded model to attribute the address as the sponsor. This scenario is suitable for the use of embedded models, so that only one query can obtain all the desired data. Second, you can see the data in an context. The structure is relatively simple.

Relationship between sponsors and addresses (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 sponsors and addresses (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"

}

]

}
 

(3) One-to-Multiple reference Document Model (References Document Model)

There is a one-to-multiple relationship between a book publisher and a book. One book can be published by multiple books in the first version, and one book can only be published by one publisher. In this case, if we still use the embedded data model, data duplication may occur. See:

{

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"

}

}

To avoid data duplication, the best way is to use the reference data model to save the book publishers and the first version of books in different sets.

When a reference model is used, the data volume between the links determines where the reference relationship is stored. If the growth of the publisher's books is very slow, 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 follows:

{

Name: "O 'Reilly Media ",

Founded: 1980,

Location: "CA ",

Books: [12346789,234 567890,...]

}

{

_ 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"

}

However, if the number of books published by the publisher is very large, this model will lead to changes in the data model, especially the increasing array. At this time, it is best to store the reference relationship on the book side, such:

{

_ 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"

}

MongoDB details: click here
MongoDB: click here

This article permanently updates the link address: