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}
Top comments (7)
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.
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 },
}
});
Hi Anshul!
I think
roleshould be a separate entity. Ausercan have multiple roles, thus it'd b best not have role information (except the ids of the roles) in theuserentityI have edited question with an example.
Having multiple roles is another scenario.
I still think you should think ahead here and have a
roleentity, theuserpoints 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
I am new to database design so considering present requirements I have designed a model. I have commented in the above post.
If anybody struggling how to design Schema in MongoDB,then here is the link to it
Link