MongoDB - one-to-many modeling

Foreword: Original address  https://www.cnblogs.com/zsychanpin/p/6881257.html

MongoDB one-to-many relationship 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%2BLIHETpodcMTcVnM7zYDBceEJhqyQJxPr3FLdcN0tJuRhTrCw%3D%3D

Remarks: This translation is not a translation in the strict sense. It is only based on the understanding of the original text and expresses it as clearly as possible. In case of doubt or inappropriateness, please refer to the original text.

Many friends who have just switched from traditional SQL development to MongoDB development will ask a question: How to use MongoDB to express one-to-many (1 to n) relationships in traditional relational databases?

Based on the rich expressiveness of MongoDB, we cannot say that we have to adopt a standard approach to 1 to n modeling.

Later we will start the explanation from 3 detailed scenarios.

first. We take n out of 1 to n for scene refinement. What magnitude does this n represent? How many to dozens? Or a few to thousands? Or thousands?

1) 1 to n (n represents several. Or dozens, not too many anyway)

For example, each Person will have multiple Addresses. In this case, we use the simplest embedded document to model.

{

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 way of modeling includes obvious advantages and disadvantages:

Advantage: You don't need to run a separate query to get all the Address information for a Person.

Disadvantage: You can't manipulate Address information as you would a standalone document.

You must first operate (for example, query) the Person document before it is possible to continue to operate the Address.

In this example, we do not need to perform a separate operation on the Address. And Address information is meaningful only after it is associated with a specific Person. So the conclusion is: the use of such embedded (embedded) modeling is very suitable for Person-Address scenarios.

2) 1 to n (n represents several, such as dozens. Even hundreds)

For example, products and parts, each product will have many parts. In such a scenario, we can use the reference method to model, such as the following:

Parts:

{

_id : ObjectID('AAAA'),

partno : '123-aff-456',

name : '#4 grommet',

qty: 94,

cost: 0.94,

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

]

}

First each part exists as a separate document. Each product includes an array type field (parts), which stores the number (_id primary key) of all the parts included in the product. When you need to query all the parts information included in the product according to a certain product number. You can run 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 such modeling methods are also obvious:

Strengths: Components exist as separate documents, and you can perform independent operations on a component. For example query or update.

Disadvantages: As above, you have to search twice to find all the parts information that a product belongs to.

In this example. This shortcoming is acceptable. It's not difficult to implement in itself. And, by modeling like this, you can easily extend 1 to n to n to n. That is, a product can include multiple parts, and 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 very large value, such as thousands. Even larger)

For example. Each host (host) will generate a very large number of log messages (logmsg).

In such cases, assuming you use embedded modeling, a host document would be so large that it could easily exceed MongoDB's document limit size. So not feasible. Suppose you use the second way to model, use an array to store the _id values ​​of all logmsg, this way is also not feasible. Because when the log is very large, even a single reference to the objectId will easily exceed the document limit size. So at this point, we do the following:

Hosts:

{

_id : ObjectID('AAAB'),

name : 'goofy.example.com',

ipaddr : '127.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 to the host in logsmg.

In summary, when modeling the 1 to n relationship, we need to consider:

1) The order of magnitude represented by n is very small. And when the entity represented by n does not need to be operated separately, embedded modeling can be used.

2) The order of magnitude represented by n is relatively large. Or when the entity represented by n needs to be operated separately, it is modeled by using Array to store references in 1.

3) When the order of magnitude represented by n is large, we have no choice. It is only possible to add a reference to the 1-side at the n-side.