Modeling user in MongoDB

Question

Our team is learning to work with MongoDB. We have to model the user among other things for an OAuth-based application. We know how to model in the relational world, but are unsure about how to do it in NoSQL.

In our application we identify the user uniquely by her email address. Email addresses are naturally unique and also verifiable. The email address seems to be a good candidate for a key.

We don't model the person. We don't have the possibility to identify a person, only her email address. That means, if a person has more than an email address, she would have several documents in the database. Also if she changes her email address she would use a different document. And also, because people login with OAuth, there's no concept of them managing their data. There's no password, and the user name is given by OAuth.

Why not using the email adress for a collection's primary key _id? Like this:

{
  _id: "john.doe@example.com",
  name: "John Doe",
  provider: "example.com",
  comments: [
    // all comments
  ]
}

What are the pros and cons of such an approach?

Edited to clarify the difference between person and user

Answer 1

This answer is not related to MongoDB in anyway, but more to the applicability of using email as a key for your user objects.

If your application is some sort of internet based application where users sign up with their email address, then it is perfectly possible that a user will get a new email address over time, and the users would want to update the registered email address.

This will lead to some challenges, if you use the email as a key.

You say you treat a person with several email addresses as several users. But there is a difference between one user having several email addresses, and one user changing his primary email to a new one. Locking down on such a design decision limits your possibilities of modifying the system in new ways in the future. At least it makes it more difficult.

If the system was some sort of internal line of business system for a company, the email might not change as it would probably be the corporate email address.

But as a general rule of thumb, I would always choose my key to be some computer generated value, and not a value that has a meaning in the real world (see surrogate key).