MongoDB modeling - how to accomplish this using a denormalized model?

Question

Let's say I have 10,000 courses with course names. And 100,000 users who sign up for various courses. My user data model would contain something like...

course: [
{courseName: 'Programming 101',
cost: 0
},
{courseName: 'How to use stackoverflow',
cost: 100
}
 ]

But if I wanted to change a course name, then that would require me to update the thousands of user records who already have that course assigned as well. What is the best way of accomplishing this? Two queries with two tables? Is this a weakness of a nosql environment, or what is the efficient way of doing so?

Answer 1

Basically you have two options:

1. Reference a course id from the user record instead of the name itself and then do a client-side join.
2. Continue to store the full course name with the student and update those fields when needed.

It really depends what you're trying to optimize your system for as to which one you choose. If you only end up changing a dozen or so course names each semester, option 2 probably won't be a problem.

Also, to answer your question about this being a weakness of nosql systems, yes, this is absolutely a weakness. This is not at all the type of problem nosql systems like Mongo are trying to solve. Mongo is great for certain problems but very bad for others. I would say that keeping a database of courses and students is not one of Mongo's strong suits. That is a prototypical relational data model and as such is more cumbersome to manage in Mongo than it would be in a classical RDBMS.

Answer 2

Actually, I would do the reverse. Users' names don't change that often.

It is better for the user to attend that class and say "Hey! My name is wrong, can you change it?" If you have a different class name then user won't be able to find you class.

This is what I'd do:

courses: [
  { coursename: 'Programming 101',
    cost: 0,
    registered: [
      {id: 11, name: 'John Doe'},
      {id: 12, name: 'Lumber Jack'}
    ]
  }
]

Answer 3

10,000 course, 100,000 users, you can use RDBMS then. If you have then 100,000 universities with 100,000 users each(10 billion users total), you are probably needing noSql....and if that is the case, playOrm allows you to do joins very easily in that situation as you could partition by university(both tables) and then you could simply do a join on "courses in universityA partition" and "users in universityA partition". Well, that is one way to go.