Question

Since it’s really not possible to return a single embedded document (yet), what is a good database design alternative?

Here is a situation. I have an object First. First has an array of Second objects. Second has an array of Third objects.

db.myDb.findOne()
{
    "_id" : ObjectId("..."),
    "Seconds" : [
        {
            "Second Name" : "value",
            "Thirds" : [
                {
                    "Third Name" : "value" 
                }
            ]
        }
    ]
}

I have a website that shows a list of First objects. You can select a First object and it will bring you to a page that shows First details which includes the list of Second objects. If you select a Second object, the same sort of thing happens.

When pulling up a Third page, it doesn’t seem right to have query to get the single First object, then some how drill down in code to get the data for the correct Third object. It would be much easier to just get a single Third object directly, possibly by _id.

Maybe I’m still too stuck in SQL land, but in this case my thought would be to create a collection for each of those types and have them reference each other, since I need to get individual objects down the tree, and don’t get to keep a reference to an object on each request, like you would be able to in a non-web app.

Would this be the correct way to solve this issue, or am I just not thinking clearly in document land?

Answer 1

I think this would depend on the usage. If you are frequently needing to access the ‘Second‘ or ‘Third‘ items without the containing ‘First‘, then perhaps they are better not being embedded.

A question I have used to help me determine whether something might be better embedded or not is to ask myself whether it is part of it or related to it. E.g, does a ‘First‘ actually contain one or more ‘Seconds‘ (and so on), or are they separate things which happen to be related in some way? On the face of it, I’d say a blog post contains comments (unless you have a compelling need to query the list of comments without knowledge of the posts), but a user/author probably does not contain a list of posts, rather they’d be linked in some way but reside in different collections.

Cross-collection relationships can be achieved with MongoDB using DBRef. This is a special type which describes a relationship with another object. If your items do belong in their own collections, they can have a DBRef to point between each other. These could go whichever way round you want (i.e. a collection of them in the First, or each Second could have one pointing to its parent first).

Example 1 – each parent has a collection of child references:

db.firsts.findOne()
{
    "_id" : ObjectId("..."),
    "Seconds" : [
        { $ref : 'seconds', $id : <idvalue> },
        { $ref : 'seconds', $id : <idvalue> },
        { $ref : 'seconds', $id : <idvalue> }
    ]
}

db.seconds.findOne()
{
    "_id" : ObjectId("..."),
    "Second Name" : "value",
    "Thirds" : [
        { $ref : 'thirds', $id : <idvalue> },
        { $ref : 'thirds', $id : <idvalue> }
    ]
}

db.thirds.findOne()
{
    "_id" : ObjectId("..."),
    "Third Name" : "value"
}

Example 2 – each child has a reference to its parent

db.firsts.findOne()
{
    "_id" : ObjectId("...")
}

db.seconds.findOne()
{
    "_id" : ObjectId("..."),
    "First" : { $ref : 'firsts', $id : <idvalue> }
    "Second Name" : "value",
}

db.thirds.findOne()
{
    "_id" : ObjectId("..."),
    "Second" : { $ref : 'seconds', $id : <idvalue> }
    "Third Name" : "value"
}

Most of the MongoDB language drivers has a way of dealing with dbrefs in a neater way than on the console (normally using some kind of ‘DBRef’ class). Working this way will mean you have more database requests, but if it makes sense to your application, it’s probably a fair compromise to make – particularly if the list of ‘Seconds’ or ‘Thirds’ in your example are commonly needed or key to interaction with the system or its functionality.

The second approach is most like you would have using a traditional relational DB. The beauty of MongoDB is that it allows you to work relationally when it actually makes sense to do so, and not when it does not. Very flexible, and ultimately it depends on your data and application as to what makes sense for you. Ultimately the answer to your question of which method you should use depends on your application and the data it stores – not something we can tell from your example.