Relational Model

1, embedded

Direct embedding "subdocuments" in a separate document

Embedded in a document (1 to 1):

{
   _id: "joe",
   name: "Joe Bookreader",
   address: {
              street: "123 Fake Street",
              city: "Faketon",
              state: "MA",
              zip: "12345"
            }
}

Embedding a plurality of documents (one pair of n), the use of "array" form:

{
   _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"
                }
              ]
 }

This is very simple.

2, post-processed manually unified ID

Late unified ID, used for association establishment procedure, more than one pair may be processed, many to many may be processed (intermediate achieved by association table), such as a typical intermediate-many tables, for determining the user's privileges: user ID- ID permission
to use the manual ID, a document that contains _id field practice in another document. Then, the application can issue a query to a second (ID) according to the analysis data required. Whether it is one to one, or many-are available.

original_id = ObjectId()

db.places.insert({
    "_id": original_id,
    "name": "Broadway Center",
    "url": "bc.example.net"
})

db.people.insert({
    "name": "Erin",
    "places_id": original_id,
    "url":  "bc.example.net/Erin"
})

3, References cited

One to one, one to many association publishers and books (many books published by publishers)
This is the correct posture, to ensure that the associated key (publisher_id) must have only one value :

publisher：
{
   _id: "oreilly",
   name: "O'Reilly Media",
   founded: 1980,
   location: "CA"
}
books：
{
   _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"
}

Incorrect reference, an array of books continues to grow, resulting in loss of control must be used to maintain an array of atomic operations.

{
   name: "O'Reilly Media",
   founded: 1980,
   location: "CA",
   books: [123456789, 234567890, ...]
}

Summary correct posture: father and son in the child table reference the parent table ID, here is the child table books, publisher parent table, in fact, the design model and the relational database is consistent.

Tree structure

1, reference parent (Parent References)

The tree structure, as shown:

Data Model:

db.categories.insert( { _id: "MongoDB", parent: "Databases" } )
db.categories.insert( { _id: "dbm", parent: "Databases" } )
db.categories.insert( { _id: "Databases", parent: "Programming" } )
db.categories.insert( { _id: "Languages", parent: "Programming" } )
db.categories.insert( { _id: "Programming", parent: "Books" } )
db.categories.insert( { _id: "Books", parent: null } )

Meaning Father cited the name suggests is each child node designated his father.

Father node retrieval query: 
db.categories.findOne ({_id: " MongoDB " }) .parent 

create an index on the field to enable quick search parent parent node: 
db.categories.createIndex ({parent: 1 }) 

by parent field query to locate its direct child node: 
db.categories.find ({parent: " Databases " }) 

to retrieve the sub-tree may be used $ graphLookup .

2, sub-references (Child References)

As the name suggests is like a father to identify his son (arrays), some models feel less reasonable. Better not stick.

db.categories.insert( { _id: "MongoDB", children: [] } )
db.categories.insert( { _id: "dbm", children: [] } )
db.categories.insert( { _id: "Databases", children: [ "MongoDB", "dbm" ] } )
db.categories.insert( { _id: "Languages", children: [] } )
db.categories.insert( { _id: "Programming", children: [ "Databases", "Languages" ] } )
db.categories.insert( { _id: "Books", children: [ "Programming" ] } )

Direct children of a node retrieval query: 
db.categories.findOne ({_id: " Databases " }) .children 
You can create an index on a field children to enable rapid search for child nodes: 
db.categories.createIndex ({children: 1 }) 
You can query node children in the field to find its parent node and its siblings: 
db.categories.find ({children: " MongoDB " })

3, the ancestor complete array (Array of Ancestors)

This is reasonable, that is, the full path to the array storage Father. Each tree node in addition to the parent node, also store the ancestor of all nodes.

db.categories1.insert( { _id: "MongoDB", ancestors: [ "Books", "Programming", "Databases" ], parent: "Databases" } )
db.categories1.insert( { _id: "dbm", ancestors: [ "Books", "Programming", "Databases" ], parent: "Databases" } )
db.categories1.insert( { _id: "Databases", ancestors: [ "Books", "Programming" ], parent: "Programming" } )
db.categories1.insert( { _id: "Languages", ancestors: [ "Books", "Programming" ], parent: "Programming" } )
db.categories1.insert( { _id: "Programming", ancestors: [ "Books" ], parent: "Books" } )
db.categories1.insert( { _id: "Books", ancestors: [ ], parent: null } )

Quick query for retrieving ancestor node or path directly: 
db.categories1.findOne ({_id: " MongoDB " }) .ancestors 

You can create an index on the field ancestors to enable quick search of the ancestor nodes: 
db.categories1. createIndex ({ancestors: 1 }) 

you can field ancestors query to find all of its descendants: 
db.categories1.find ({ancestors: " Programming " })


Array of Ancestors pattern provides a quick and effective solution to find the descendants and ancestors of a node by creating an index field ancestor element. It is the development and application of a good choice.

4, a path materialized (Materialized Paths)

And an array of ancestral works exactly the same, but offers greater flexibility in the processing path, such as finding nodes by partial paths.

db.categories.insert( { _id: "Books", path: null } )
db.categories.insert( { _id: "Programming", path: ",Books," } )
db.categories.insert( { _id: "Databases", path: ",Books,Programming," } )
db.categories.insert( { _id: "Languages", path: ",Books,Programming," } )
db.categories.insert( { _id: "MongoDB", path: ",Books,Programming,Databases," } )
db.categories.insert( { _id: "dbm", path: ",Books,Programming,Databases," } )

您可以查询以检索整个树，按字段path排序：
db.categories.find().sort( { path: 1 } )
您可以在path字段上使用正则表达式来查找Programming的后代：
db.categories.find( { path: /,Programming,/ } )
您还可以检索Books的后代，其中Books也位于层次结构的最顶层 level：
db.categories.find( { path: /^,Books,/ } )
要在字段path上创建索引，请使用以下调用：
db.categories.createIndex( { path: 1 } )
此索引可能会根据查询提高 performance：
对于来自根Books sub-tree(e.g. /^,Books,/或/^,Books,Programming,/)的查询，path字段上的索引可显着改进查询性能。
对于 sub-trees 的查询，其中查询(e.g. /,Databases,/)中未提供根的路径，或者 sub-trees 的类似查询，其中节点可能位于索引 string 的中间，查询必须检查整个索引。
对于这些查询，如果索引明显小于整个集合，则索引可以提供一些性能改进。

One of MongoDB developers in-depth: Detailed document data relational model (one to many, many to many)