MongoDB Data Modeling - References

So far in our MongoDB series, we’ve talked mainly about CRUD (create, read, update, delete), and in the last article we covered the D, deleting documents and even their collections. The bottom line is, that’s all we really need in order to run a database that someone else built. But in real world, at some point you’re going to have to build and design your own databases, or at least part of them. And even if you happened to have been given a database that’s complete from top to bottom, the time will come when you’ll at least need to create your own collection.

So for this very reason we’re going to talk a bit about data modeling, or in other words, how to represent data in MongoDB. It’s a bit harder than what you might think since most of us (including me, or especially me!) are used to thinking in terms of relational databases. This means when we’re planning out or databases we start thinking about JOINs, something that for better or worse doesn’t exist in MongoDB. Also concepts like Foreign Keys, which come very natural to us, don’t really exist either. In principle, MongoDB works best when we don’t normalize the database. But if we do want to create a certain level of normalization, then here we’ll talk about what’s available to us and how to create it.

And if you don’t have any idea what normalization is and where I’m coming from with this stuff, then do a bit of googling and get up to speed.

The most common problem, the kind you’re likely to run into, is a page with comments—a talkback page but without chain comments for convenience sake. So let’s imagine an example, say we’ve got two things: the first is a page with a body, title, and id, and the second are comments that have a body, title, id, and also page_id—since each comment belongs to a certain page.

If we were using MySQL, then the page_id would be the Foreign Key of the comment, and when we wanted to retrieve the comments we would run a query on the comments table, with our Foreign Key. So far, nice and easy—but can we do this in MongoDB? Well, the answer is… of course we can! Remember, MongoDB makes an id for us, and we can and should use that id where we need it.

There are two main ways to use references. This first way is manual and easy as can be—let’s assume we have a table called pages:

for (i = 0; i < 100; i++) {var title="number "+i;var body = "Page Body Number "+i;    db.pages.insert({"title":title,"body":body});}

This code will make a pages table with 100 pages. Something that looks a bit like:

{ "_id" : ObjectId("541e99d7f5e52579d9d7b625"), "title" : "number 14", "body" : "Page Body Number 14" }

Let’s say someone left a comment on page 14. In the document of that comment all we need to do is put in the ObjectId of the page to which we’re responding to a section that will be easy for us to retrieve it later on. Something like this:

db.comments.insert({"title":"Comment title","body":"body title","page":ObjectId("541e99d7f5e52579d9d7b625")})

So what the problem? Well, this is something that the application is supposed to do. It’s a legitimate way to do things, but there is another more useful way called Database Reference or DB REF. It’s important for me to point out that we’re talking about a convention here—that is, as opposed to Foreign Key which is required, here we’re talking about something not required. This means you can put all kinds of random stuff into ObjectId and MongoDB won’t make a fuss or anything.

In principal, DB REF requires of us both the ObjectId that we are connection to and the name of the collection that’s inside of the document we’re connecting to. We enter in these two data items like so:

db.comments.insert({
   "title": "Comment title",
   "body": "body title",
   "page": {
       "$ref": "pages",
       "$id": ObjectId("541e99d7f5e52579d9d7b625")
   }
})

You can see that this is very similar to manual entry of the ObjectId. So why go through all this to use it? First off, here we’ll have all the details of from which collection the document being referred to came.  Second, when we execute a call, MongoDB does a preload in some of its drivers to objects that have references—something that can be really great for performance (or totally unnecessary, depending on the app). In principle, MongoDB’s documentation recommends using manual reference, unless you have a good reason not to. An example of a good reason would be, absolute certainty that you’ll call to documents that have references, immediately after you execute a call to a document that contains it. For example, if you call to an invitation that has a reference to the user that created it, and the application needs to display the details of the user.

In new versions of MongoDB, you can execute DE REF not only on other collections but even to another database.

In the next article we get into embedded documents.

About the author: Ran Bar-Zik is an experienced web developer whose personal blog, Internet Israel, features articles and guides on Node.js, MongoDB, Git, SASS, jQuery, HTML 5, MySQL, and more. Translation of the original article by Aaron Raizen.