First of All

Hey new Devs, how are you doing?
Please follow me on twitter so we can interact more =D

Introduction

Learning Ruby on Rails is an awesome experience. I have been overwhelmed for its potential at the very first tutorial I took. It's amazing how with only a few commands and changes on files can result in your pages.

The first steps of building your web application are creating and correctly connecting the database of its application, but most of the text that should help with a bit more advanced topics are confusing.

Migrations

This is the very first step when building any Rails application. Creating the tables for your application is pretty easy. Just run on the terminal:
rails generate model modelName.

Model

At this point, is now time to connect each table as it has to be. For example, in this example, an Appointment must be a mutual agreement between Doctor and Patient. That is the diagram after the main connection we are creating.

Simple Relations

In order to create these associations, let's recall the fundament here. Creating a one-to-many association requires that the 'one' part of the relation has_many relation; the 'many' part of the model needs the belongs_to relation. In this example, a patient can attend to multiple appointments, but an appointment can have only one patient, so:

This is the simplest relation that can be built on Rails. A has_many requires a relation name and if the model-relation is the name of another class, it automatically refers to that class, requiring a 'class-name_id'. This association works fine because the belongs_to creates a reference for the column that it exists (on this example, patient_id, created since the first migration).

But there are some moments in which this is not that simple. At some tutorials, this is the point that starts to be confusing, but it is still simple! It's shown on the relation for the Doctor model.

Nicknamed Relations

This kind of association is way more used and readable on the code. The fundament here is that the programmer can create nicknames for its association that represents exactly its purpose, and the tags are pretty much the same.

The change on the has_many tag is that now it's required to point the relation to the correct class and foreign_key.
In order to complete the relation, the belongs_to tag that goes on the Appointment model refers to a doctor and points it to the Doctor ID (Primary Key). Since the column is not named directly to the class name, it must also point which column of the model is to refer to the Doctor table.

Advanced Relation

So far, the fundament of creating direct relations should be fully understood. What about the SOURCE - THROUGH relations? Those are a bit tricker.

Source - Through Fundament

Most of the topics I have read about this relation were really confusing (and actually, this is what inspired me to write this article). There are a lot of paragraphs that explain everything in a too much technical way, that means almost nothing to beginners, especially if your mother language is not English (like me). So, is it that confusing?
spoiler-alert: NO.

The best analogy for this association is to think about getting a car ride from your friends. The same way, the association through-source works getting 'rides' on other associations.

In this example, the association who_attend of the Doctor class gets a ride first on the association Doctor-->Appointment THROUGH the to_attend association (now, the pointer is at the Appointment Class). Next, it takes a ride on the association Appointment-->Patient SOURCE the patient association.

Wrapping up

I encourage you to build the same application and test it in many different ways. First, finish this simple application building the association for the Patient-->Doctor using the same concept.

Also, don't stop there! Build as many different applications you can just to practice the fundament of the relations.

Fundaments are important! Focus on it, buddy!