CODEWITHSUNDEEP
mongodbnosql
AndreFeijo
AndreFeijo

Reputation: 10629

MongoDB update paradigm

Trying to get my hands dirty with MongoDB, coming from a relational database background.

I believe one of the main concepts of MongoDB is to keep as much data together as possible.

Imagine I create an application that have products and categories, and I store products this way:

Products collection

{
    "_id": "30671", //main item ID
    "department": "Shoes",
    "category": "Shoes/Women/Pumps",
    "brand": "Calvin Klein",
    "thumbnail": "http://cdn.../pump.jpg",
    "title": "Evening Platform Pumps",
    "description": "Perfect for a casual night out or a formal event.",
    "style": "Designer",
    …
}

Categories collection

{
    "_id": "12356",
    "name": "Shoes"
    …
}

If I update a category name, would I need to run a huge update command to update all products as well? Or in this scenario it would be better to actually store the category ids against the products instead of their names (like we would do on a relational database)?

Thanks

Upvotes: 0

Views: 89

Answers (1)

kevinadi
kevinadi

Reputation: 13775

In general there is no "one-size-fits-all" approach in MongoDB like it is in relational database world. In a relational schema design, it is a no-brainer to put Category in a separate table. In fact, it is almost a requirement to do so during normalization process.

In MongoDB, schema design almost entirely depends on what you need and your use case more than any rule-of-thumb or any formulated requirements. Of course, there are pluses/minuses for each choice. For example:

  • If you find in your use case that Category doesn't change much (or at all), then you can safely put it inside the Products collection. However, should you need to rename a category, then yes you would need to update all the products belonging to that category.
  • If you find that your use case requires flexibility in changing category names, then you may want to put it into a separate collection and refer to it like in a relational design. However, returning a product may not be as performant since now you need two queries instead of one (or a lookup).

I noticed that you used "category": "Shoes/Women/Pumps" in your example. In MongoDB, you can put that into an array if your use case allows it, e.g. "category": ["Shoes", "Women", "Pumps"]. This may make the field easier to index (again, depending on your use case).

In short, there is no right or wrong in MongoDB schema design with one caveat: usually the wrong thing to do is trying to emulate a relational design in MongoDB, since it goes against the grain.

You also may find these links helpful:

Upvotes: 1

Related Questions