Why do we need a through table explained with Rails?

In a many to many relationship, it's just a table between the entities, but what is the purpose of this table to be between them?

Let's explain it with an example, in Rails we can create two models and these 2 models can be connected just with a foreign key by Active Record Associations.

rails g model User name  

rails g model Event name user_id:integer

Now that we have created these 2 models (Don't forget to migrate the models with rails db:migrate) Event and User, how do we connect them? Well, the user_id is going to be our foreign key, remember that primary keys are unique between models, so in order to reference our User model. We can start saying "A User can have many events but an Event belongs to one single user". Therefore, to make that happen we need to use the reserved words has_many and belongs_to like this:

class User < ApplicationRecord
    has_many :events
end

class Event < ApplicationRecord
    belongs_to :user
end

Great! Now we can start playing with our associations and Rails will make 2 assumptions :

1) The class of the model your association points to is based directly off of the name of the association.

2) The foreign key in any belongs_to relationship will be called yourassociationname_id.

In our Rails console we can now do something like this:

user = User.new;
user.name = "Fernando"
user.save

event = Event.new
event.name = "The big Party"
event.user = user

Ok, so we created a new User called "Fernando" and we created a new Event called "The big Party" thanks to our belongs_to we can use

event.user

event.save

We can get our user for that specific event! as an Active Record with

event.user

#<User id: 1, name: "Fernando", created_at: "2020-10-06 17:14:30", updated_at: "2020-10-06 17:14:30">

Now to get all the events that this User has we can do

user.events

#<ActiveRecord::Associations::CollectionProxy [#<Event id: 1, name: "The biggest party", user_id: 1, created_at: "2020-10-06 17:33:01", updated_at: "2020-10-06 17:33:01">]>

Do you see the difference? The difference is that in one query we received an Active_Record while on the other query related to the events we received a CollectionProxy, CollectionProxy is nothing more than an array since a user can have multiple events, but remember an event can have only 1 User.

Now let's complicate things a little bit more...

Imagine that you want your "users to attend many events, but only one user to be the owner for that specific event?" We can think in a way to create another model called

Invitee

Invitee

Event

Invitee

User

So we can say something like this: "A User can have many events and can attend many events" and "An Event can have many attendees but it only belongs to one single user ". We can now see clearly that we have a Many/Many relationship between these 2 models. So what approach should we take?

First, we need 2 Foreign-Keys one for the Owner and one for the Attendee, we can add a new column to our Event model with the command:

rails g migration add_column_owner_id_to_events owner_id:integer

rails db:migrate.

Ok, now that we have a new column called

owner_id

user_id

owner_id 

class User < ApplicationRecord
    has_many :events, foreign_key: "owner_id", class_name: "Event"
    has_many :attending_events, class_name: "Event"
end

Note here that I changed to

:attending_events

User.first.attending_events 

Now we need to create some owners for those events, lets create 3 more users as we did before and also 1 more event. If you did everything right ... You should now have 3 Users. Now let's assign those events an owner.

ev1 = Event.first
ev2 = Event.second

ev1.owner = User.first
ev2.owner = User.second

# Update the events with the **save** method

ev1.save
ev2.save

class Event < ApplicationRecord
    belongs_to :owner, class_name: "User"
    has_many :attendees,foreign_key: "id", class_name: "User"
end

Now we can see the owner for each event by saying for the first event :

ev1.owner

owner_id

Event Model

id

ev1.attendees 

user.id

foreign_key: "id"

Now, let's analyze some problems that we have here ... For example, if we create a new Attendee for the same event, we will need to create the same event but with a different user_id on the Event model, imagine if we have 1,000 attendees we will have 1,000 event instance of the same event, but with different user_ids on the same model making it impossible to query it!

What should we do?

Through table.....

Yes, a Through table is what we need, to keep our attendees in a separate table and to leave our unique Event in its own model. So how does it works?

First let's get one thing straight... Let's remove the

user_id

rails g migration remove_user_id_from_events user_id:integer

rails db:migrate

Let's generate our new model to work as a communication between User & Event. By conversion this table is called by the name of the 2 models (User & Event) concatenated. So it can be called EventUser, UserEvent. I'm going to call it EventAttendee, since we want to show all of our attendees for a specific event. We generate our new model as before with:

rails g model EventAttendee event_id:integer attendee_id:integer

Now we set up our through table saying that the

event_id

attendee_id

class EventAttendee < ApplicationRecord
    belongs_to :event, class_name: "Event"
    belongs_to :attendee, class_name: "User"
end

Now, let's configure our User model to communicate with our EventAttendee through table.

class User < ApplicationRecord
    has_many :events, foreign_key: "owner_id", class_name: "Event"
    has_many :event_attendees, foreign_key: "attendee_id"
    has_many :attending_events, through: :event_attendees, source: :attendee
end

Ok.. Let's explain what we did here...

has_many :event_attendees, foreign_key: "attendee_id" 

attendee_id

has_many :attending_events, through: :event_attendees, source: attendee

:attending_events 

:event_attendees

source: ...

:attending_events

attendee_id

source: :attendee

attendee_id column 

:attending_events

Now let's configure our Event model to communicate with our EventAttendee through table.

class Event < ApplicationRecord
    belongs_to :owner, class_name: "User"
    has_many :event_attendees, foreign_key: "event_id"
    has_many :attendees, through: :event_attendees, source: :event
end

Let's explain again but now with Event model

has_many :event_attendees, foreign_key: "event_id"

:attendees

:event_attendees

:attendees

:event

Now we can see each of our events attendees, events owners, the events that the user is attending, and the infrastructure is pretty well organized that let us query single events for the Event model. Just by adding another table through our model in our many to many relationship...