Getting to know: Active Record

Ruby and Rails have an awesome take on MVC, specifically in the Models. As many know, Ruby/Rails is sometimes considered a “magical language” because of all of the amazing things you can do with some of the gems out there. The gem I’d like to focus on today is the every so important Active Record, and how it can help us develop our models, and their relationships.

Active Record- Relationships

When we first start a project, the most important thing to do is go over the relationships our Models/Classes will have with each other. Say we have three models- Doctor, Patient, and Appointment.

                  Patient -< Appointment >- Doctor

Here is where we can see how our classes will interact with each other. A patient can have many appointments, and a doctor can also have many appointments. However, patients and doctors cannot have any of each other unless an appointment is made. This is a mouth-full to explain without showing some code, so let’s see what our classes would look like (in a normal project, these would each be inside their own .rb file):

class Patient < ActiveRecord::Base
      has_many :appointments
      has_many :doctors, through: :appointments
end

class Doctor < ActiveRecord::Base
      has_many :appointments
      has_many :patients, through; :appointments
end

class Appointment < ActiveRecord::Base
      belongs_to :patient
      belongs_to :doctor
end

What active record is doing is allowing our classes to communicate with each other. We use has_many :exampleClass to show how information will be stored. Active record lets our code know that a Patient can know about their appointments, but they won’t know about which doctor they will see until they’ve made an appointment. This is shown in the has_many :exampleClass, through: :exampleClass2 section in both the Patient and Doctor classes.

In order for an appointment to be made, two key pieces of information need to be known. We’ll need to know which patient this appointment belongs to and which doctor our appointment will belong to. Without an appointment, no one gets help with their illness.

Active Record- Models

So now we have our relationships built out and we’re ready to start building out our classes to hold information important to them, like our patients and doctors names. Here are what our tables should look like before we migrate them to our database.

class CreatePatients < ActiveRecord::Migration[5.2]
  def change
  create_table :patients do |t|
   t.string :patient_name
   t.string :insurance_type
  end
 end
end

class CreateDoctors < ActiveRecord::Migration[5.2]
 def change
  create_table :doctors do |t|
   t.string :doctor_name
   t.string :doctor_type
   t.string :insurance_accepted
  end
 end
end

class CreateAppointments < ActiveRecord::Migration[5.2]
  def change
  create_table :appointments do |t|
   t.integer :appointment_time
   t.integer :doctor_id
   t.integer :patient_id
  end
 end
end

What active record is doing here is creating a table that will be saved to our database. In each of these tables, the information that our classes need to exist will be stored. This way, each instance can hold different information. That will make it so we can have many different doctors, appointments, and patients in our application!

A Word on Foreign Keys

Remember our belongs_to: relationship from the first section of this article? Well, when one of our classes belongs to another, it’s important that we somehow tell Active Record to let our database know this. In addition to writing what we did before, we also put foreign keys into our tables. In our Appointments table above, we can see that our class is going to hold information for both a doctor_id, and a patient_id. This way, an appointment cannot be made without the id of both a patient and a doctor.

When our classes inherit from Active Record, it allows us to build real world relationships in a digital space.