MongoDB one-to-multiple link Modeling

This blog is translated from:

Http://blog.mongodb.org/post/87200945828/6-rules-of-thumb-for-mongodb-schema-design-part-1? Mkt_tok = 3RkMMJWWfF9wsRonsq7Ldu % 2FhmjTEU5z14uUsUKGxhokz2EFye % 3D % 3D

Note: This translation is not strictly translated. It is only based on the understanding of the original article and can be clearly expressed as much as possible. If you have any questions or problems, refer to the original article.

Many people who have just switched from traditional SQL development to MongoDB development will ask the following question: how to use MongoDB to express one-to-many (1 to n) Relationships in traditional relational databases?

Based on MongoDB's rich expressiveness, we cannot say that we must adopt a standard method for 1 to n modeling. Later, we will explain it in three specific scenarios.

First, we will refine the n in 1 to n. What is the magnitude of n? How many to dozens? Or how many to thousands? Or thousands?

1) 1 to n (n represents several, or dozens, not too many)

For example, each Person has multiple addresses. In this case, we use the simplest embedded document for modeling.

{  name: 'Kate Monster',  id: '123-456-7890',  addresses : [     { street: '123 Sesame St', city: 'Anytown', cc: 'USA' },     { street: '123 Avenue Q', city: 'New York', cc: 'USA' }  ]}

This modeling method contains obvious advantages and disadvantages:

Advantage: you do not need to perform a separate query to obtain all Address information of a Person.

Disadvantage: you cannot operate the Address information as in an independent document. You must first perform operations (such as querying) on the Person document before continuing to operate on the Address.

In this instance, we do not need to perform independent operations on the Address, and the Address information is meaningful only after it is associated with a specific Person. Therefore, the conclusion is that embedded (embedded) modeling is very suitable for the Person-Address scenario.

2) 1 to n (n represents a few, such as dozens or even hundreds)

For example, products and parts, each Product has many parts. In this scenario, we can use the reference method for modeling, as shown below:

Parts (Part): {_ id: ObjectID ('aaa'), partno: '2017-aff-456 ', name:' #4 grommet ', qty: 94, cost: 123, price: 3.99} Product ):
{    name : 'left-handed smoke shifter',    manufacturer : 'Acme Corp',    catalog_number: 1234,    parts : [     // array of references to Part documents        ObjectID('AAAA'),    // reference to the #4 grommet above        ObjectID('F17C'),    // reference to a different Part        ObjectID('D2AA'),        // etc    ]}

Each part is used as a separate document. Each product contains an array type field (parts), which stores the numbers of all parts contained in the product (_ id Primary Key ). When you need to query information about all parts contained in a product according to a product number, you can perform the following operations:

> product = db.products.findOne({catalog_number: 1234});   // Fetch all the Parts that are linked to this Product> product_parts = db.parts.find({_id: { $in : product.parts } } ).toArray() ;

The advantages and disadvantages of this modeling method are also obvious:

Advantage: Parts exist as independent documents. You can perform independent operations on a part, such as querying or updating.

Disadvantage: As shown above, you must query it twice to find information about all parts of a product.

In this example, this disadvantage is acceptable and is not difficult to implement. Moreover, with this modeling, you can easily extend 1 to n, that is, a product can contain multiple components, at the same time, a part can be referenced by Multiple Products (that is, the same part can be used by multiple products ).

3) 1 to n (this n represents a large number, for example, thousands or even larger)

For example, each host generates a large amount of log information (logmsg ). In this case, if you use embedded modeling, a host file will be very large, which easily exceeds the document size limit of MongoDB, so it is not feasible. If you use the second method for modeling and use an array to store the _ id values of all logmsg, this method is also not feasible, because many, even referencing objectId alone will easily exceed the document size limit. Therefore, we use the following methods:

Machine (hosts): {_ id: ObjectID ('aaab'), name: 'goofy .example.com ', ipaddr: '2017. 66.66.66 '} log (logmsg): {time: ISODate ("2014-03-28T09: 42: 41.382Z"), message: 'cpu is on fire! ', Host: ObjectID ('aaab') // Reference to the Host document}

We can store the _ id reference of the host in logsmg.

To sum up, when modeling a 1 to n relationship, we need to consider:

1) WHEN n represents a small order of magnitude, and n represents an entity that does not need to be operated independently, embedded modeling can be used.

2) When n represents a large order of magnitude, or n represents an entity that needs to be operated independently, it is modeled by storing references in Array in 1.

3) n indicates that when the order of magnitude is very large, we have no choice but to add a reference to end 1 on end n.