@@ -16,58 +16,49 @@ Database References
16
16
:class: singlecol
17
17
18
18
For many use cases in MongoDB, the denormalized data model where
19
- related data is stored within a single :term:`document <document>` will
20
- be optimal. However, in some cases, it makes sense to store related
19
+ related data is stored within a single :term:`document <document>` is optimal.
20
+ However, in some cases, it makes sense to store related
21
21
information in separate documents, typically in different collections
22
22
or databases.
23
23
24
24
.. important::
25
25
26
- MongoDB 3.2 introduces :pipeline:`$lookup` pipeline stage to perform
26
+ You can use the :pipeline:`$lookup` pipeline stage to perform
27
27
a left outer join to an unsharded collection in the same database.
28
- For more information and examples, see :pipeline:`$lookup`.
29
28
30
- Starting in MongoDB 3.4, you can also use :pipeline:`$graphLookup`
31
- pipeline stage to join an unsharded collection to perform recursive
32
- search. For more information and examples, see
33
- :pipeline:`$graphLookup`.
29
+ You can also use the :pipeline:`$graphLookup` pipeline stage to join an
30
+ unsharded collection to perform recursive search.
34
31
35
32
This page outlines alternative procedures that predate the
36
33
:pipeline:`$lookup` and :pipeline:`$graphLookup` pipeline stages.
37
34
38
- MongoDB applications use one of two methods for relating documents:
35
+ MongoDB applications use one of two methods to relate documents:
39
36
40
- - :ref:`Manual references <document-references>` where you save the
37
+ - :ref:`Manual references <document-references>` save the
41
38
``_id`` field of one document in another document as a reference.
42
- Then your application can run a second query to return the related
39
+ Your application runs a second query to return the related
43
40
data. These references are simple and sufficient for most use
44
41
cases.
45
42
46
43
- :ref:`DBRefs <dbref-explanation>` are references from one document to another
47
44
using the value of the first document's ``_id`` field, collection name,
48
- and, optionally, its database name. By including these names, DBRefs
49
- allow documents located in multiple collections to be more easily linked
50
- with documents from a single collection.
51
-
52
- To resolve DBRefs, your application
53
- must perform additional queries to return the referenced
54
- documents. Many :driver:`Drivers </>` have helper
55
- methods that form the query for the DBRef automatically. The
56
- drivers [#official-driver]_ do not *automatically* resolve DBRefs
57
- into documents.
58
-
59
- DBRefs provide a common format and type to represent relationships among
60
- documents. The DBRef format also provides common semantics for representing
61
- links between documents if your database must interact with
62
- multiple frameworks and tools.
45
+ and, optionally, its database name, as well as any other fields. DBRefs allow
46
+ you to more easily reference documents stored in multiple collections or
47
+ databases.
48
+
49
+ To resolve DBRefs, your application must perform additional queries to return
50
+ the referenced documents. Some :driver:`MongoDB drivers </>` provide helper
51
+ methods to enable DBRefs to be resolved into documents, but it doesn't happen
52
+ automatically.
53
+
54
+ DBRefs provide a common format and type to represent relationships among
55
+ documents. The DBRef format also provides common semantics for representing
56
+ links between documents if your database must interact with
57
+ multiple frameworks and tools.
63
58
64
59
Unless you have a compelling reason to use DBRefs, use manual
65
60
references instead.
66
61
67
- .. [#official-driver] Some community supported drivers may have
68
- alternate behavior and may resolve a DBRef into a document
69
- automatically.
70
-
71
62
.. _document-references:
72
63
73
64
Manual References
@@ -76,7 +67,7 @@ Manual References
76
67
Background
77
68
~~~~~~~~~~
78
69
79
- Using manual references is the practice of including one
70
+ A manual reference is the practice of including one
80
71
:term:`document's <document>` ``_id`` field in another document. The
81
72
application can then issue a second query to resolve the referenced
82
73
fields as needed.
@@ -132,7 +123,11 @@ Background
132
123
DBRefs are a convention for representing a :term:`document`, rather
133
124
than a specific reference type. They include the name of the
134
125
collection, and in some cases the database name, in addition to the
135
- value from the ``_id`` field.
126
+ value from the ``_id`` field.
127
+
128
+ Optionally, DBRefs can include any number of other fields. Extra field names
129
+ must follow any :ref:`rules for field names <limit-restrictions-on-field-names>`
130
+ imposed by the server version.
136
131
137
132
Format
138
133
~~~~~~
@@ -156,8 +151,6 @@ DBRefs have the following fields:
156
151
Contains the name of the database where the referenced document
157
152
resides.
158
153
159
- Only some drivers support ``$db`` references.
160
-
161
154
.. example::
162
155
163
156
DBRef documents resemble the following document:
@@ -177,13 +170,15 @@ DBRefs have the following fields:
177
170
"creator" : {
178
171
"$ref" : "creators",
179
172
"$id" : ObjectId("5126bc054aed4daf9e2ab772"),
180
- "$db" : "users"
173
+ "$db" : "users",
174
+ "extraField" : "anything"
181
175
}
182
176
}
183
177
184
178
The DBRef in this example points to a document in the ``creators``
185
179
collection of the ``users`` database that has
186
- ``ObjectId("5126bc054aed4daf9e2ab772")`` in its ``_id`` field.
180
+ ``ObjectId("5126bc054aed4daf9e2ab772")`` in its ``_id`` field. It also contains
181
+ an optional field.
187
182
188
183
.. note::
189
184
0 commit comments