MongoDB one-to-many relationship modeling

Tag: Person obj res produces object mbed SQL friend array

This blog post 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

Note: This translation is not strictly translated, but is expressed as clearly as possible based on the understanding of the original. If in doubt or inappropriate, please refer to the original.

Very many friends who have just shifted from traditional SQL development to MONGODB development ask a question: How do you use MongoDB to express a one-to-many (1 to n) relationship in a traditional relational database?

Based on the rich expressive power of mongodb, we cannot say that we must adopt a standard method for modeling 1 to N.

We'll start with 3 detailed scenarios later.

First of all. We refine the scene for N in 1 to N. What magnitude does this n represent? Is it a few to dozens of? Or a few to thousands of? Or thousands of them?

1) 1 to N (n stands for several. Or dozens of, not too much anyway)

For example, each person will have multiple address. In this case, we modeled with the simplest embedded document.

{  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 approach includes obvious strengths and weaknesses:

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

Cons: You can't manipulate address information as you do with standalone documents.

You must first manipulate (for example, query) the person document before you can continue to manipulate the address.

In this example, we do not need to operate the address independently. The address information is only meaningful if it is linked to a specific person. So the conclusion is that the use of such embedded (embedded) modeling is well suited for person-address scenarios.

2) 1 to N (n stands for many, for example, dozens of). Even hundreds of)

For example, product and component (part), each product will have very many components. In this scenario, we are able to model by reference, 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 (' F1 7C '),    //reference to a different part        ObjectID (' D2AA '),        //etc    ]}

First each part is present as a separate document. Each product includes an array type field (parts), which holds the number of all components included in the product (_id primary key). When you need to query all part information that is included in the product based on a product number. You can run the following actions:

> Product = Db.products.findOne ({catalog_number:1234});   Fetch all the Parts that is linked to this product> Product_parts = Db.parts.find ({_id: {$in: Product.parts}}) . ToArray ();

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

Advantage: The component is present as a standalone document, and you can operate on a part independently. For example, query or update.

Cons: As above, you must have two queries to find all the part information that a product belongs to.

In this example. This shortcoming can be accepted. It is not difficult to realize itself. And, with this modeling, you can easily extend 1 to N. That is, a product can include multiple parts, and at the same time a part can be referenced by multiple products (i.e. the same part can be used by multiple products).

3) 1 to N (this n represents very large values, for example, tens of thousands.) Even larger)

Example. Each host generates a very large amount of log information (LOGMSG).

In this case, assuming that you are using embedded modeling, a host document can be very large and easily exceed the size of the MongoDB document limit. So it's not feasible. Let's say you modeled in the second way, using arrays to hold all logmsg _id values, which is not the same way. Due to the very long log, it is easy to exceed the document limit size even if you refer to Objectid alone. So at this point, we take the following approach:

Host (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 a 1 to n relationship, we need to consider:

1) n represents a very small order of magnitude. And the entities represented by N do not need to be operated separately, they can be modeled with embedded.

2) n represents a larger order of magnitude. or n represents an entity that needs to be operated on its own, modeled by using an array to store references in 1.

3) n represents a large order of magnitude, we have no choice. Only a reference to the 1 end can be added to the N-end.

MongoDB one-to-many relationship modeling