Being introduced to Complex object-oriented programming languages was a pinnacle moment in my coding development. Coming from a background that mostly developed in C, OOP and Active Record’s framework made starting and planning projects feel less intimidating and overbearing. The combination of OOP and Active record allowed me the ease of organizing my ideas into neat tables that modeled real life scenarios. Active records join-table functionality is crucial to representing and accessing data between objects that are associated with one another.

RELATIONSHIPS AND KEYWORDS-
Objects in Ruby might exist as separate .rb files in a directory and those files are seemingly independent of one-another. In fact they are independent of each-other initially. Through Active record key-words we can create an association between various different objects to reflect how they will interact post-production! For example, in my Spotify-esque application I have playlists and users. Step away from code and think about the relationship of those two objects in Spotify. A user can have created many playlists, but a playlist can only belong to one user initially (not including shared playlists). However, a playlist has many songs but a song belongs to many playlists. Through active keywords like like “has many”, “belongs to”, and, “has many through,” a developer has the ability to represent these relationships clearly. Below is a visual representation of these objects and their relationship.

As you can see there are two tables between "Song-Playlist" and "Song-Artist." These are examples of join-tables. Lets dive into the code itself to find how this is represented!

Active Record utilizes join-tables to create associations. By storing one object id within the table of another object a relationship created. Migration files are created to represent these relationships. In this example we have created a table, in our migration directory, that stores playlists and songs.

This is the model for the PlaylistsSongs join table. Hopefully these keywords are screaming some sort of relationship to you. If you scroll between this model and the diagram you'll quickly realize just how intuitive creating these associations become. I find it easier to understand "belongs_to" if I think of cattle branding. When a cow "belongs to" a cattle rancher that cow is branded with the ranchers symbol. Think of that brand as cattle_rancher_id and each cow has a brand. The same goes for songs and playlists. Here are their models:

If you refer back to line 2 of song.rb and line 6 of playlist.rb you will notice a complex keyword that at first glance is intimidating. Don't worry! This is a key word just like "belongs_to" or "has_many" but "has_and_belongs_to_many" just represents the many-to-many relationship between song and playlist. Using my cattle rancher metaphor, each cow has many brands from different rancher and each rancher has many cows that they share with other ranchers. In this case each song has multiple playlist brands and each playlist has multiple song brands.

Now that we have the relationships set up lets refer back to our join table:

This is the quintessential step in relating these two objects. Now whenever we want a list of all songs in a playlist we can simply write code that is along these line:

This returns an array of song_ids that are associated with that playlist! It is important to note though that the objects themselves aren’t actually being stored, rather a reference to those objects through an integer data type called an id.

Now you should have a better grasp on Active Record and just how intuitive it is to organize relationships amongst different class objects in OOP languages. By using keywords and tables we can take seemingly independent .rb files and make them interact with one-another. What a wonderful gem!