Rich : Many to Many Association

Greetings Geek,

In this article, we're gonna add more complexity to our join tables. I call these rich joins. First, to understand why we need this complexity, let's go back to the many-to-many diagram for the beginning of this chapter. This is a classic many-to-many example. We have a number of courses, we have a number of students taking these courses. There will be a table named courses and a table named students, and in the simple join, we would have a join table between them, which we would call courses_students.

In the join table will be two foreign keys, one for the course, and one for the student. Here's where the simple join falls short, though.Imagine that we wanna keep track of more information than just the fact that a student is participating in a class. You might wanna keep track of their seat number, or the date they signed up, or the date they last attended, or how many times they've been absent. That information belongs in this join table, 'cause the join table is essentially the object maintaining the presence of the student in the course. Everything that has to do with Michael and his participation in Chemistry should be stored in that join.

This is when we need to switch to a rich join. One of the benefits of a rich join is that we no longer have to follow Rails table-naming conventions. Instead, it's a good idea to give it a name that describes the join. I've named it course_enrollments. You could just as easily name it student_enrollments. We're not just renaming the table, though. We're also gonna be creating a new model for our course_enrollments. Instead of using has_and_belongs_to_many between course and student, now course will have many course_enrollments, and so will students.

Course Enrollment is going to have two belongs_to definitions, one for course and one for student. In the previous movie, you'll remember that I said that many-to-many associations work just like has_many associations? Well, here, that's actually true. They are has_many associations now. Course Enrollment still serves as a join between them. It's just now a join that can have more richness. It can have more columns in the database, more attributes, and more custom methods stored in that model. We use rich joins for the same reason that we use a simple join.

The difference is only that we get more complexity on the join. Because of that, we need to change the way that we store this relationship in the database. We're going to have a join table still, with two indexed foreign keys, but because it has a model for the join, it's also going to require having a primary key defined, so we will need to have an (:id) now, so that we can create this record, find it, update it, and delete it,just like we can with any active record object. There's no table-naming convention that we need to follow, however, one helpful tip is that rich join table names often will end in "-ments" or "-ships", such as "assignments", "engagements", "authorships", "memberships".

If you find yourself trying to think of a good name, remember that names with those endings often work well. In our application, we will use rich joins with Admin User and Section. The idea is that every time an AdminUser updates a Section of the CMS, we're gonna keep track of the edit in a table called section_edits. We'll have a model for it called Section Edit. Then we'll have admin_user has_many :section_edits,and SectionEdit belongs_to :admin_user. Then on the other side of the join, we'll have Section has_many :section_edits, and SectionEdit belongs_to :section.

CHEERS,
Maitrey Patel