I have a schema which shares multiple fields between my model. Here are a simple representation of the schemas.
const productSchema = new mongoose.Schema({
productName: String,
productId: String,
productAltCode: String,
description: String,
}
const cartSchema: new mongoose.Schema({
productId: String,
productAltCode: String,
...
}
Here I have 2 fields which are the same in both models, productId and productAltCode. Is there a way to not duplicate in both schemas? I have this type of scenario with other objects in my model and just think there may a way to not duplicate the fields
Related
Using the MERN stack I am able to add a document (a Property Schema in this case) via Mongoose. The issue is one of the Property Keys (Rooms in this case) is an Array of Objects. When I initially create the Property I don't send any data regarding the Rooms but a blank Object is created, albeit with a MongoDB _id?
I thought Mongoose prevented creating blank Objects / Arrays if no data was sent or am I confusing matters? Why is it happening? And is there a way to prevent this?
Just to be clear when I initially create the Property I'm sending no information and I don't even reference the rooms array in the data sent from axios.
Here is my Schema:
const propertySchema = new Schema({
propertyId: String,
propertyName: String,
rooms: [
rId: String,
type: String,
class: String,
view: String,
price: String
]
})
Arrays implicitly have a default value of [] (empty array).
But you can prevent it by giving a default: undefined option like this:
const propertySchema = new Schema({
propertyId: String,
propertyName: String,
rooms: {
type: [
new Schema({
rId: String,
type: String,
class: String,
view: String,
price: String,
}),
],
default: undefined,
},
});
Docs (in the Arrays section)
What I realised was I had two controllers, postPropertyController and patchPropertyController. As described in the question when I post the property for the first time I don't include anything in the req.body about the rooms. However, in the postPropertyController I was still doing this...
const propertySchema = new Schema({
propertyId: String,
propertyName: String,
rooms: [
rId: String,
type: String,
class: String,
view: String,
price: String
]
})
What I needed to do to clear the empty object in the rooms array was this...
const propertySchema = new Schema({
propertyId: String,
propertyName: String,
rooms: []
})
Later in the application flow I used a patch method and the patchPropertyController to update the rooms array.
Shout out to #suleymanSah for suggesting something that made me take another look at the code side by side.
I'm curious about the best way to represent this kind of situation in Mongo. I have my own idea, but I'm curious on what the general consensus/best practice actually would be.
Imagine I have two collections:-
Employees
--> _id
--> FirstName
--> Surname
--> Email
Comments
--> _id
--> PersonReference
--> CommentDate
--> Comment
Now imagine that Employees can come and go and the 'Employees' collection is always up-to-date. However, in the event that an employee has ever made a comment, the full information on the comment including who made it must be available.
The way I would propose to tackle this problem, is to organise the structure like this instead:-
Employees
--> _id: _id
--> FirstName: string
--> Surname: string
--> Email: string
Comments
--> _id: _id
--> CommentDate: date
--> Comment: string
[-] --> PersonReference
[+] --> Employee: object { _id: id, FirstName: string, Surname: string, Email:string }
So essentially, I would have a list of 'Active Employees' and at a time where a comment is made, I would duplicate the employee information into the Comments collection document (rather than use a reference).
From a high level perspective, is this considered best practise?
Many thanks
Duplicating the employee info in the comments collection is really a bad idea.
When an employee info needs to be changed, it will also needs to be updated in the comments.
You have a few options:
1-) Embedding the comments inside the Employee schema:
In this method we have no separate Comments collection.
If you have no need to independently query comments, this method makes sense.
This way we can access a user and his/her comments in one db access and without needing any join (populate or lookup).
The schema for this can be like this:
const mongoose = require("mongoose");
const employeeSchema = new mongoose.Schema({
firstName: String,
username: String,
email: String,
comments: [
new mongoose.Schema({
commentDate: Date,
comment: String
})
]
});
module.exports = mongoose.model("Employee", employeeSchema);
2-) Parent referencing:
In this method we keep the reference of the comments in the Employee schema.
If you don't need to access to employee from a comment, this can an option.
Employee Schema:
const mongoose = require("mongoose");
const employeeSchema = new mongoose.Schema({
firstName: String,
username: String,
email: String,
comments: [
{
type: mongoose.Schema.Types.ObjectId,
ref: "Comment"
}
]
});
module.exports = mongoose.model("Employee", employeeSchema);
Comment Schema:
const mongoose = require("mongoose");
const commentSchema = new mongoose.Schema({
commentDate: Date,
comment: String
});
module.exports = mongoose.model("Comment", commentSchema);
3-) Child referencing
In this method we keep reference of the employee in the comments.
So if you need to access the comments from an employee we need to use Populate Virtual feature of mongoose. Becase in employee schema we don't have a reference to the comments.
Employee Schema:
const mongoose = require("mongoose");
const employeeSchema = new mongoose.Schema(
{
firstName: String,
username: String,
email: String
},
{
toJSON: { virtuals: true } // required to use populate virtual
}
);
// Populate virtual
employeeSchema.virtual("comments", {
ref: "Comment",
foreignField: "employee",
localField: "_id"
});
module.exports = mongoose.model("Employee", employeeSchema);
Comment Schema:
const mongoose = require("mongoose");
const commentSchema = new mongoose.Schema({
commentDate: Date,
comment: String,
employee: {
type: mongoose.Schema.Types.ObjectId,
ref: "Employee"
}
});
module.exports = mongoose.model("Comment", commentSchema);
4-) Both parent and child referencing:
With this method, it is possible to select comments from employee, and employee from comments. But here we have some kind of data duplication, and also when a comment is deleted, it needs to be done in both of the collections.
const mongoose = require("mongoose");
const employeeSchema = new mongoose.Schema({
firstName: String,
username: String,
email: String,
comments: [
{
type: mongoose.Schema.Types.ObjectId,
ref: "Comment"
}
]
});
module.exports = mongoose.model("Employee", employeeSchema);
Comment Schema:
const mongoose = require("mongoose");
const commentSchema = new mongoose.Schema({
commentDate: Date,
comment: String,
employee: {
type: mongoose.Schema.Types.ObjectId,
ref: "Employee"
}
});
module.exports = mongoose.model("Comment", commentSchema);
Many database implement kind of no-delete collections, implementing a delete/active flag for each document.
For example, Employees collection would become :
Employees
--> _id: _id
--> FirstName: string
--> Surname: string
--> Email: string
--> Active: boolean
This way, you keep track on employees data that has been deleted, and prevent documents duplication if you have database size restrictions.
PS: nowadays you can be tackled keeping user data if they ask deletion (RGPD)
EDIT: This solution with boolean may not work if Employees document is updated and you want to keep employees firstname,name,mail,etc at the time he made the Comment.
I'm about to build a Node.js+Express+Mongoose app and I'd like to pick the community's brains and get some advice on best practices and going about creating an efficient schema design.
My application is going to include 2 different user types, i.e "teacher" and "student". Each will have a user profile, but will require different fields for each account type. There will also be relationships between "teacher" and "student" where a "student" will initially have 1 teacher (with the possibility of more in the future), and a "teacher" will have many students.
My initial thoughts about how to approach this is to create a general User model and a profile model for each user type (studentProfile model & teacherProfile model), then reference the appropriate profile model inside the User model, like so (A):
var UserSchema = new Schema({
name: String,
email: String,
password: String,
role: String, /* Student or Teacher */
profile: { type: ObjectID, refPath: 'role' }
});
var studentProfileSchema = new Schema({
age: Number,
grade: Number,
teachers: [{ type: ObjectID, ref: 'Teacher' }]
});
var teacherProfileSchema = new Schema({
school: String,
subject: String
});
Or do I just go ahead and directly embed all the fields for both profiles in the User model and just populate the fields required for the specific user type, like so (B):
var UserSchema = new Schema({
name: String,
email: String,
password: String,
role: String, /* Student or Teacher */
profile: {
age: Number,
grade: Number,
school: String,
subject: String
},
relationships: [{ type: ObjectID, ref: 'User' }]
});
The downside to option B is that I can't really make use of Mongoose's required property for the fields. But should I not be relying on Mongoose for validation in the first place and have my application logic do the validating?
On top of that, there will also be a separate collection/model for logging students' activities and tasks, referencing the student's ID for each logged task, i.e.:
var activitySchema = new Schema({
activity: String,
date: Date,
complete: Boolean,
student_id: ObjectID
});
Am I on the right track with the database design? Any feedback would be greatly appreciated as I value any input from this community and am always looking to learn and improve my skills. What better way than from like minded individuals and experts in the field :)
Also, you can see that I'm taking advantage of Mongoose's population feature. Is there any reason to advise against this?
Thanks again!
You could try using .discriminator({...}) function to build the User schema so the other schemas can directly "inherit" the attributes.
const options = {discriminatorKey: 'kind'};
const UserSchema = new Schema({
name: String,
email: String,
password: String,
/* role: String, Student or Teacher <-- NO NEED FOR THIS. */
profile: { type: ObjectID, refPath: 'role' }
}, options);
const Student = User.discriminator('Student', new Schema({
age: Number,
grade: Number,
teachers: [{ type: ObjectID, ref: 'Teacher' }]
}, options));
const Teacher = User.discriminator('Teacher', new Schema({
school: String,
subject: String
}, options));
const student = new Student({
name: "John Appleseed",
email: "john#gmail.com",
password: "123",
age: 18,
grade: 12,
teachers: [...]
});
console.log(student.kind) // Student
Check the docs.
One approach could be the following:
//Creating a user model for login purposes, where your role will define which portal to navigate to
const userSchema = new mongoose.Schema({
_id:mongoose.Schema.Types.ObjectId,
name: {type:String,required:true},
password: {type: String, required: true},
email: {type: String, required: true},
role:{type:String,required:true}
},{timestamps:true});
export default mongoose.model("User", userSchema);
//A student schema having imp info about student and also carrying an id of teacher from Teachers Model
const studentSchema = new mongoose.Schema({
_id:mongoose.Schema.Types.ObjectId,
age:{type:Number},
grade:{type:String},
teacher:{type:mongoose.Schema.Types.ObjectId,ref:'Teachers'}
},{timestamps:true});
export default mongoose.model("Students", studentSchema);
//A teacher model in which you can keep record of teacher
const teacherSchema = new mongoose.Schema({
_id:mongoose.Schema.Types.ObjectId,
subject:{type:String},
School:{type:String},
},{timestamps:true});
export default mongoose.model("Teachers", teacherSchema);
I'm defining my schema in mongoose and I have an array of book objects, and then an "active book". Now setting it up wasn't an issue, but this seems like unnecessary repetition to define the exact same book object in two different parts of the schema.
var BookSchema = new Schema({
activeBook: {
id: String,
title: String,
author: String,
pages: Number
},
books: [{
id: String,
title: String,
author: String,
pages: Number
}]
});
Is there a cleaner way of writing this so I don't have to write out the same object everywhere I use it?
A cleaner way would be to create a subdocument, a document with a schema of its own which are elements of a parent's document array. So in your example above you can define the child/parent schema as follows:
var ChildSchema = new Schema({
id: String,
title: String,
author: String,
pages: Number
});
var ParentSchema = new Schema({
activeBook: ChildSchema,
books: [ChildSchema]
});
I have a Company schema:
var CompanyEntityModel = new Schema({
name: String,
street: String,
zipCode: String,
city: String,
members: [Useraccount]
});
And a Useraccount schema:
var UseraccountEntityModel = new Schema({
firstName: String,
lastName: String,
email: String,
password: String,
companies: [Company],
});
In my scenario I save the useraccounts in a useraccount collection (inside the db) and as embedded document inside the company. So a company can have n useraccounts.
I do the same with companies (they are saved inside a company collection and as embedded document inside a useraccount. A useraccount can have n companies).
I could also just save the objectIds to members (in Company schema) and to companies (in Useraccount schema).
What is better? If I stick to my solution and the company gets updated ... do I have to update the document in my companies collection and also all the companies which are embedded documents inside the useraccounts?
that might help you: http://docs.mongodb.org/manual/reference/database-references/
My preferred way is saving the object id into the second collection and perform on application side an second query to get related data.