ORM, Ruby and ActiveRecord.
Right off the bat, what is ORM? Literally, it means object relational mapping — but if you are like me, that meant absolutely nothing. It sounded nice though.
Object. Relational. Mapping.
Incalculable deep dives later, I decided to break through the ambiguity to break down the concepts, integrations and functionality of ORM frameworks. Going forward, navigating databases no longer has to be exhausting or anxiety-provoking.
If you’re coding in an object-oriented programming language, harnessing the power of ORM simplifies and organizes the implementation of a relational database within your OO-language of choice.
Concepts: What does an ORM framework do?
ORM is the middle wo/man between a relational database management system and your preferred object-oriented programming language. She eases communication between both parties so that the conversation is more fluid, graceful and intuitive. This support is called mapping.
Mapping, or sometimes referred to as wrapping, draws connecting vectors between the database and your language’s models — or “wraps” your queries in more direct, personable code.
While developing programs, ORM provides conventional methods for integrating a database into your code. It allows you to access a database table like a Ruby class and a row of your table like an instance of your class, as illustrated below.
Integrations: Who can use an ORM?
There are different types of ORM frameworks depending on the object oriented language you’re using. Languages conventionally accepted as functional can also have designated ORM systems to support a language’s more object-oriented functionality.
Although an ORM framework is more frequently created to simplify the interaction between a relational database and an object-oriented language, languages like JavaScript encapsulate this aforementioned exception.
Functionality: How do an ORM framework and an OO-language interact?
Using Ruby as my object-oriented programming language and SQL (Structured Query Language) as my relational database, the following examples will flow through adding class instance’s to a table with the purpose of visually comparing the greater simplicity of each process.
The table below illustrates what we’d like our code to produce: a list of giraffe friends with corresponding characteristics.
Basic Addition.
Imagining we have just created a new giraffes table, the lines below illustrate how we would use the SQL function INSERT INTO to hardcode our giraffe friends into our table one by one. It gets the job done but if we had anymore friends (giraffes are nice, so it’s possible), our program would quickly resemble the DMV — inefficient and slow.
Simplifying with Methods.
There’s a lot more code here. How could it be simpler? Well, as we continue to make more giraffe friends we want to be able to add them to our table with more ease now and less code later. By creating a model with several class methods we can 1) collect all of our giraffes in one array using self.all and 2) add them to our table using self.save — all without having to write INSERT INTO forty seven hundred times. Arbitrary number. Real talk.
ORM Implementation.
ActiveRecord is the most-adopted ORM framework by Rubyists — You can install it here.
At its core, ActiveRecord is a library that, through extensive and detailed development, enables you to call SQL functions more intuitively and precisely. As Ruby on Rails built-in ORM, ActiveRecord at its most basic level allows you to interact with data using CRUD methods — create, read, update and destroy. By inheriting these ActiveRecord base methods, your class instantly has access to basic CRUD functions that can clean up your code.
For example, when building out our giraffes table, the difference between typing out SQL CRUD queries in the example above and using ActiveRecord is that, ActiveRecord’s base methods turn 6–10 words into one.
Simply, you are inheriting pre-defined functionality, like so:
Now if you wanted to add a new giraffe friend to the table, you would use ActiveRecord’s built-in create function to insert a new row to the table.
So instead of having to create new class methods in our Ruby program every time we wanted to manipulate or call our data, we can inherit those features from ActiveRecord and simply create, read, update or destroy.
Attitudes: What are the benefits and drawbacks of using an ORM?
There are hundreds of discussions debating the value of ORMs over raw database queries, like SQL. The bell-curve consensus encapsulates a hybrid approach emphasizing: the benefits of ORM frameworks for simple, tedious CRUD functionalities and raw SQL’s for complex join tables and larger projects that benefit from more explicit (and therefore speedier) directions.
In this Hacker News discussion, I found several great one-liners exemplifying mainstream moods towards object relational mapping frameworks.
Your pro-ORM advocates generally propose something like,
“Life is too short to maintain every single query.”
While your SQL or raw database query proponents argue,
“ORMs add a layer of complexity to your code and a huge risk of really bad SQL.”
Often ORM can serve as a crutch that alienates true understanding of a database and how it works. However, if your foundational knowledge of SQL (or your preferred relational database) is sound and comprehensive, harnessing an ORM’s capacity to support your program can be a truly powerful exhale.
