CODEWITHSUNDEEP
node.jsmongodbrestify
Ali Yousuf
Ali Yousuf

Reputation: 702

MongoDB Database design for different type of users

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

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?

Upvotes: 2

Views: 3059

Answers (3)

user1955934
user1955934

Reputation: 3495

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

Upvotes: 1

Joost Vunderink
Joost Vunderink

Reputation: 1236

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.

Upvotes: 4

edencorbin
edencorbin

Reputation: 2949

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

Upvotes: 0

Related Questions