CODEWITHSUNDEEP
mongodbdatabase-designmodel
Shih-Wen Su
Shih-Wen Su

Reputation: 2689

MongoDB object model design with list property

I just started to use MongoDB and I'm confused to build object models with list property. I have a User model related to Followers and Following object which are list of User IDs. So I can think of some object model structures to represent the relation.

  1. Embedded Document. Followers and Following are embedded to User model. In this way, a "current_user" object is generated in many web frameworks in every request, and it's an extra overhead to serialize/deserialize the Follower and Following list property since we seldom use these properties in most requests. We can exclude these properties when "current_user" is generated. However, we need to fetch full "current_user" object again before we do any updates to it.

  2. Use Reference Property in User model. We can have Followers and Following object models themselves, not embedded, but save references to the User object.

  3. Use Reference Property in Followers and Following models. We can save User ID in Follower and Following property for later queries.

There might be some other ways to do it, easier to use or better performance. And my question is:
What's the suggested way to design a model with some related list properties?

Upvotes: 0

Views: 643

Answers (1)

William Z
William Z

Reputation: 11129

For folks coming from the SQL world (such as myself) one of the hardest things to learn about MongoDB is the new style of schema design. In the SQL world, everything goes into third normal form. Folks come to think that there is a single right way to design their schema, because there typically is one.

In the MongoDB world, there is no one best schema design. More accurately, in MongoDB schema design depends on how the application is going to access the data.

Here are the key questions that you need to have answered in order to design a good schema for MongoDB:

  • How much data do you have?
  • What are your most common operations? Will you be mostly inserting new data, updating existing data, or doing queries?
  • What are your most common queries?
  • What are your most common updates?
  • How many I/O operations do you expect per second?

Here's how these questions might play out if you are considering one-to-many object relationships.

In SQL you simply create a pair of master/detail tables with a primary key/foreign key relationship. In MongoDB, you have a number of choices: you can embed the data, you can create a linked relationship, you can duplicate and denormalize the data, or you can use a hybrid approach.

The correct approach would depend on a lot of details about the use case of your application.

Here are some good general references on MongoDB schema design.

MongoDB presentations:

Here are a couple of books about MongoDB schema design that I think you would find useful:

Here are some sample schema designs:

Upvotes: 1

Related Questions