Menu
Assuming the following "schema/relationship" design what is the recommended practice for handling deletion with cascade delete like operation?
Relational Schema:
+---------+ +--------+ | Student |-*--------1-[Enrollment]-1--------*-| Course | +---------+ +--------+
MongoDB:
+---------+ +--------+ | Student |-*----------------*-| Course | +---------+ +--------+
Given this classic design of enrollment of students to courses, having a collection of courses in students and vice versa seems to be an appropriate data model when using MongoDB (that is nothing for the relationship/enrollment table). But coming from a relational world how should I handle the semantics of deleting a course? That is, when a course is deleted, all the "enrollment" records should be deleted too. That is, I should delete the course from the collection of each student record. It looks like I have to fire 2 queries: one for deleting the course and then to delete it from each student's collection. Is there a way to have a single query to perform this "cascade delete" like semantic without the additional query? Does the data model need to change?
NOTE: For all other use cases the above data model works just fine:
=> just delete that student and associated collection of courses deleted along with it.=> just delete it from the student collection of courses=> just add it to corresponding 'table' in essence.The only tricky thing is handling the deletion of a course. How should I handle this scenario in MongoDB, since I hail from a relational background and am unable to figure this one out.
567
Using those concepts, it allows a “cascading'' delete, which means a primary key parent delete will delete the related siblings. MongoDB allows you to form relationships in different ways—for example, by embedding documents or arrays inside a parent document.
A foreign key with cascade delete means that if a record in the parent table is deleted, then the corresponding records in the child table will automatically be deleted. This is called a cascade delete in SQL Server.
One of the primary benefits of creating Embedded Relationships in MongoDB is that the queries are executed faster than the referenced relationship. This relationship also improves performance, and results are obtained quickly. This is also true for large datasets.
MongoDB has two types of relationships. Embedded and Reference made. Every relationship has its advantages and usages. These relationships help in improving performance.
What you are doing is the best and most optimal way of doing it in Mongo. I am in a similar situation and after going all possible implementations of the N:M design pattern, have also arrived to this same solution.
Apparently, This is not a mongodb thing, but more of a concept of NoSQL, wherein, the less changing data (Courses) can be kept separately. And since deleting a Course is not going to be a very frequent operation, its feasible enough to go through all the records to remove it.
On the other hand, you could let it be as it is. In your application logic, just ignore the values of Courses in the Student document that don't have a reference_id in the Course document at all. But in that case, you must make sure that old deleted Course_id's are not being reused.
OR just use the deleted flags on the Course document and handle everything else in your application logic.
188
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
