0

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

  • So if a person changes the email-address for whatever reason (used a company address and left the company, ...) they have to register again? From a user perspective this doesn't sound very user-friendly (no difference, if used in SQL or NoSQL world). – Simon Jul 4 '13 at 8:21
  • This is by design because we don't know if they are really the same person. And there's no real "registering" because of OAuth. They just allow Facebook or Gmail or Github to give contact details. – nalply Jul 4 '13 at 8:23
  • You have listed all the normal arguments to not use a natural value as primary key in a database together with your reasoning why this argument doesn't apply to your situation, so you already answered your question yourself: go for it, when you think it will work for you. – Philipp Sep 2 '13 at 12:28
2

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).

  • It's a design question in the NoSQL world. There are different design guidelines for NoSQL and SQL. And secondly, I realize that I didn't tell the whole s tory. – nalply Jul 4 '13 at 8:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.