Database Reference
In-Depth Information
▪ The particular profile data stored for the user is isolated into the
profile
subdocument,
allowing us to evolve the profile's schema as necessary without worrying about name col-
lisionswithotherpartsoftheschemathatneedtoremainfixedforsocialgraphoperations.
Of course, to make the network interesting, it's necessary to add various types of posts. We'll
put these in the
social.post
collection:
{
_id
:
ObjectId
(...),
by
:
{
id
:
"T4Y...AE"
,
name
:
'Max'
},
circles
:
[
'*public*'
],
type
:
'status'
,
ts
:
ISODateTime
(...),
detail
:
{
text
:
'Loving MongoDB'
},
comments
:
[
{
by
:
{
id
:
"T4Y...AG"
,
name
:
'Dwight'
},
ts
:
ISODateTime
(...),
text
:
'Right on!'
},
...
all comments listed
... ]
}
Here, the post stores minimal author information (
by
), the post
type
, a timestamp
ts
, post de-
tails
detail
(which vary by post type), and a
comments
array. In this case, the schema embeds
all comments on a post as a time-sorted flat array. For a more in-depth exploration of the other
approaches to storing comments, refer back to
Storing Comments
.
A couple of points are worthy of further discussion:
▪ Author information is truncated; just enough is stored in each
by
property to display the
author name and a link to the author profile. If a user wants more detail on a particular
author, we can fetch this information as they request it. Storing minimal information like
this helps keep the document small (and therefore fast.)
▪ The visibility of the post is controlled via the
circles
property; any user that is part of
one of the listed circles can view the post. The special values
*public*
and
*circles*
allow the user to share a post with the whole world or with any users in any of the posting
user's circles, respectively.
▪ Different types of posts may contain different types of data in the
detail
field. Isolating
this polymorphic information into a subdocument is a good practice, helping to identify
