DEV Community

loading...

designing database

anshulnegitc profile image Anshul Negi ・1 min read

I am new to database architecture though familiar with queries and aggregation in MongoDB.
At present working on a project where I have to store different user depending upon the type/role. There are few fields similar in the user model, would it be correct to create a separate collection for each role or just create separate schema then reference it i.e only a single collection.
In the future, more roles can be added with more information.
Any other approach is welcome.

Below is the mock models
Eg:
*customer =
{firstname,lastname,email,address,mobileno,password,role}
*sales = {firstname,lastname,email,address,mobileno,password,role,attachments,experience,
education}
*marketting =
{teamName,email,address,mobileno,password,role,members,attachments}

Discussion (7)

pic
Editor guide
Collapse
brandinchiu profile image
Brandin Chiu

How a database is designed is determined heavily by the engine used.

In this case, a noSQL database through MongoDB requires less structure to use. That's one of the inherent benefits of a noSQL model.

You're actively choosing to reduce the overhead of your data store. This means your data integrity must be managed by your application instead.

In that case, it really doesn't matter that much what your overall schema looks like, so long as its comfortable to use, and isn't excessively horizontal in scale (many different records vs alot of data in single records).

What you have above is totally reasonable, but understand that it would look very different in a relational model.

I would however suggest changing role to roles as an array of role objects.

You can then be safe knowing that your data will handle multiple roles form the start.

Collapse
anshulnegitc profile image
Anshul Negi Author

This is how I have designed Model

const userSchema = mongoose.Schema({
email: { type: String, require: true },
address: { type: String, require: true },
role:{ type: String, require: true },
password:{ type: String, require: true },
extraInformation: {
firstname: { type: String, minlength: 1, maxlength: 255, require: true },
lastname: { type: String, minlength: 1, maxlength: 255, require: true },
sales : {
attachments: { type: String, minlength: 1, maxlength: 255, require: true },
experience: { type: String, require: true, minlength: 1, maxlength: 255 },
education: { type: String, require: true, minlength: 1, maxlength: 255 },
}
},
marketting: {
teamName: { type: String, minlength: 1, maxlength: 255 },
members: { type: String, minlength: 1, maxlength: 255, require: true },
attachments: { type: String, minlength: 1, maxlength: 255 },
}
});

Collapse
rhymes profile image
rhymes

Hi Anshul!

I think role should be a separate entity. A user can have multiple roles, thus it'd b best not have role information (except the ids of the roles) in the user entity

Collapse
anshulnegitc profile image
Anshul Negi Author

I have edited question with an example.
Having multiple roles is another scenario.

Collapse
rhymes profile image
rhymes

I still think you should think ahead here and have a role entity, the user points to. A user "can" have multiple roles means they can still have 1 and be totally fine. It'd probably be harder to change the schema afterwards.

The balance is how costly joins with this new entity are, but I'm not familiar with MongoDB much to be of help for this. It probably depends also on the size of your DB

Thread Thread
anshulnegitc profile image
Anshul Negi Author • Edited

I am new to database design so considering present requirements I have designed a model. I have commented in the above post.

Collapse
anshulnegitc profile image
Anshul Negi Author

If anybody struggling how to design Schema in MongoDB,then here is the link to it
Link