MongoDB Database design for different type of users

Question

I'm making a RESTful API for a website where there are multiple type of users.

Admin
Vendors (Company name, address)
Regular Users (Name, phone)

The users will always be whatever they initially registered as (permanent specialization).

I'm using Mongoose and NodeJS, and I have come up with the following Model for User so that I can easily manage login with new Social websites in future.

{
  userType: { type: String, lowercase: true },
  contact: {
    email: { type: String, lowercase: true, index: { unique: true, sparse: true } }
  },
  accounts: {
    local: { password: String },
    facebook: { id: String, token: String }
  }
}

So my question is, since I have different type of users and each type has different profile information, where should I store information regarding each of them?

Make different models for each type and add a reference key in User model? Or is there a better way?

Joost Vunderink · Accepted Answer · 2016-01-03 17:11:05Z

4

I don't think that putting this information in different collections is a good idea here. One of MongoDB's strengths is that you can put all relevant user information in a single document, so you can retrieve it with 1 query.

I would add 3 fields to the user model:

adminInfo: { ... },
vendorInfo: { ... },
userInfo: { ... },

and fill the right one, depending on the user type. The other 2 fields can be null (or even not present at all).

Don't go the normalisation route - it's not needed here.

answered Jan 3, 2016 at 17:11

Joost Vunderink

1,2468 silver badges14 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

Ali Yousuf Over a year ago

This sounds perfect. In fact, I have read somewhere that in NoSQL, we don't do much normalization.

nab Over a year ago

what if admin and vendor share some information but user don't ?

Learning PHP OOP Over a year ago

how do i handle a situation where we have the different user fields? for example candidate and employer where candidate has email, password, resume, experience, skills and so on where employer has email, password, company size, company history and so on do i have to create everything in a single user modal? or create user plus two separate models for candidate profile and employer profile? i am from the relational database side so it is bit confusing.

user1955934 · Accepted Answer · 2020-10-31 03:17:37Z

1

If you're thinking long term, i think it is best to make separate collections. In my experience, these fields will keep adding as complexity increases. Imagine if you had to write queries to select by vendor specific flags and also user specific flags; these queries would be add up and it can be huge. Also, imagine if you had a lot of user type checks: if (type == VENDOR) all over the place...

It will take an initial effort to make them as separate collection; but will be worth it in longer terms..

answered Oct 31, 2020 at 3:17

user1955934

3,5756 gold badges47 silver badges78 bronze badges

Comments

edencorbin · Accepted Answer · 2016-01-03 16:19:28Z

The question seems to be on general database design. I would recommend any and all fields that are shared between users be in your user model, and then fields that are specific to one kind of user stored in a model specifically for that, for instance "Admin", if a user is only ever 1 type of user, you could store the type as you do, and a generic ID field, and then find the appropriate user type specific data based on the type and the ID field. Alternatively, you could have an id and model relationship for each user type and not make any of these fields required as well as check for null. This latter approach may give you flexibility down the road to allow a user to be of multiple types (possibly choosing which to log-in as).

Collectives™ on Stack Overflow

MongoDB Database design for different type of users

3 Answers 3

3 Comments

Comments

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

3 Comments

Comments

Comments

Your Answer

Sign up or log in

Post as a guest

Related