Database Reference
In-Depth Information
Independent Collections
The first collection,
social.user
, stores the social graph information for a given user along
with the user's profile data:
{
_id
:
'T4Y...AC'
,
// base64-encoded ObjectId
name
:
'Rick'
,
profile
:
{ ...
age
,
location
,
interests
,
etc
. ... },
followers
:
{
"T4Y...AD"
:
{
name
:
'Jared'
,
circles
:
[
'python'
,
'authors'
] },
"T4Y...AF"
:
{
name
:
'Bernie'
,
circles
:
[
'python'
] },
"T4Y...AI"
:
{
name
:
'Meghan'
,
circles
:
[
'python'
,
'speakers'
] },
...
],
circles
:
{
"10gen"
:
{
"T4Y...AD"
:
{
name
:
'Jared'
},
"T4Y...AE"
:
{
name
:
'Max'
},
"T4Y...AF"
:
{
name
:
'Bernie'
},
"T4Y...AH"
:
{
name
:
'Paul'
},
... },
...}
4
},
blocked
:
[
'gh1...0d'
]
}
There are a few things to note about this schema:
▪ Ratherthanusinga“raw”
ObjectId
forthe
_id
field,we'lluseabase64-encodedversion.
Although we
can
use raw
ObjectId
values as keys, we can't use them to “reach inside” a
document in a query or an update. By base64-encoding the
_id
values, we can use queries
or updates that include the
_id
value like
circles.10gen.T4Y...AD
.
▪ We're storing the social graph bidirectionally in the
followers
and
circles
collections.
While this is technically redundant, having the bidirectional connections is useful both for
displaying the user's followers on the profile page, as well as propagating posts to other
users, as we'll see later.
▪ In addition to the normal “positive” social graph, this schema above stores a block list that
contains an array of user IDs for posters whose posts never appear on the user's wall or
news feed.
