Why you should use Subcollections in MongoDB

Introduction

Having an organized database architecture is invaluable. If your data is organized cleanly, it’s easier to read, easier to maintain, and easier to work with in general. One aspect of organizing in MongoDB that we see under-utilized is the use of Subcollections. Subcollections sound slightly intimidating and a lot of developers didn’t even know they existed, and for good reason. Subcollections are more of a naming decision than anything else but we feel that using them makes sense in a lot of situations and is worth a discussion.

What are Subcollections?

If you haven’t heard of Subcollections don’t feel like you’ve been missing out on something, because a Subcollection is just the same old MongoDB collection that you’ve always dealt with.

So what is a Subcollection? Well, sometimes when you’re working with collections it makes sense to organize similar collections together. For example if you had a database for a grocery store database grocerydb, you might have some collections related to products and you might have some collections related to employees. These two types of collections are distinct and unrelated. But the collections about products ARE related and you might want to explicitly indicate that. For example you might have one collection with information about each products, and another about the distributors for each product. For this it might make sense to name your collections products.info and products.distributors. This would indicate to other developers that these collections are related. We should re-iterate that there would be nothing different about these collections, they would have no more or fewer features, they are just collections that happen to have a . in their name.

Namespacing

Using the same name followed by the . is called namespacing and indicates to other developers that these collections are related. MongoDB allows .s in their collection names and this allows us developers a convenient and easy way to namespace our collections. In fact you can use the . multiple times so if you wanted to continue to create related collections you could use products.distributors.local and products.distributors.foreign.

Our Recommendation

We recommend that you use Subcollections where it makes sense, which in our experience is in a lot of situations. Sit down and think about which collections can be grouped together and namespace those collections. Remember that it doesn’t have to stop at one level but you can continue to use the . to do deeper levels like we mentioned before (products.distributors.local and products.distributors.foreign).

Conclusion

Although naming your collections may seem like a small decision we believe that giving them some thought ahead of time will save you a lot of time down the line. There’s nothing worse than having confusing database names and fields that you constantly have to remind yourself what they mean. Using Subcollections is one easy way to fight off ambiguity and keep your data clean and organized.

If you have any questions about your MongoDB instance or are thinking about having your database managed by a service please don’t hesitate to reach out to us at Object Rocket. We’re always more than happy to talk data.