MongoDB Database Design Principles

1. A couple of very few one-to-few can take an inline document

in the person collection

{

Name: ' Zhang San ',

AGE:20,

address:[

{country: " China " , Shanxi Province , city: " Changzhi "} Span style= "font-family: the song Body;" >,

{Country: " China ",province: " Shanxi Province ",City: " Taiyuan City "}

]

}

Pros: There's no need to execute a single statement to get inline content

Cons: The method accesses these embedded documents as separate entities

Application: Couple rarely and do not need to access inline content separately

2. a couple of many (but not many) one-to-many Intermediate references

Person Collection

{

_id:objectid ( three bytes )

Name: " Zhang San "

Age:23

}

People Group Collection

{

Name: " a group ",

persons:[

ObjectID ("AAAAA"),

ObjectID ("AAABBB")

.....

]

}

Application: A one-to-many and many-sided content can be referenced by an array of multiple parties for various reasons that need to exist separately.

3. a pair of very many one-to-squillions Parent references (mongodb maximum 16M per document )

Company Collection

{

_id:objectid ("Company01")

Name: " available for the Times "

}

Employee Collection

{

Name: " Zhang San ",

Age:23,

Company:objectid ("Company01")

}

Application: In a very numerous case, embed the one-side reference into a multi-end object.

4. bidirectional correlation saves each other's references on one side and many side

Person Collection

{

_id:objectid ("Person01"),

Name: " Zhang San ",

Age:23,

Group:objectid ("Group01")

}

Group Collection

{

_id:objectid ("Group01"),

Name: " develop a group ",

persons:[

ObjectID ("Person01")

ObjectID ("Person02")

]

}

Pros: With a one-to-many advantage, at the same time on the many side, you can quickly find less of the party

Disadvantage: Updates require that you update references in two collections at the same time, and you cannot use atomicity

5. Inverse Paradigm

Inverse paradigm many-<one : Redundant mony -side data to one side that is stored in one party mony collection of references

Inverse Paradigm noe-<many: redundant one -side data to many side is saved on the side of the many A reference to one

Use occasions: Read relatively high, update less than the case (no atomicity)

7. General design principles

A. give priority to embedding, unless there are compelling reasons.

B. you need to access an object individually, and that object is not intended to be embedded in other objects.

C. arrays should not grow indefinitely. If there are hundreds of document objects on the many side, do not embed them with a reference to the ObjectID scheme, if there are thousands of document objects, then do not embed an array of ObjectID. Which scenarios to take depends on the size of the array.

D. Please confirm the read/write ratio before designing the inverse paradigm. A field that is barely changed to be read only is suitable for redundancy into other objects.

MongoDB Database Design Principles