When it comes to web development, it's no secret that data management is one of the most crucial aspects of any project. The ability to properly manage and interact with our database(s) is absolutely imperative to the overall success of our applications. After all, without adequate data management, we are left with mere static webpages that don't actually offer much practicality, let alone substance. Working with data certainly does not come without its challenges however. As we continue to add complexity to our back-end we are faced with an overwhelming sea of data, often nested beyond timely comprehension.

To help alleviate the pain associated with overcoming some of these obstacles, many developers opt to implement ORM.

What Is ORM?

In programming ORM stands for object-relational mapping; a technique for converting data between type systems using object-oriented programming languages. Essentially it acts as a layer between the language and the database, helping programmers work with data without the OOP (object-oriented programming) paradigm. Rather than writing raw SQL (a programming language specific to database interaction and management) to query (a request to access data) and manipulate data, developers can utilize an ORM framework to access data in their preferred language.

Here are some reasons why you may want to consider implementing an ORM to avoid having to write raw SQL queries:

Advantages of ORMs

There's no doubt that ORM frameworks like Ruby's Active Record, or Java's Hibernate can be advantageous under the right circumstances.

Comfort

One of the biggest selling points of ORM frameworks is their ability to allow developers to code in their preferred language. As you progress through a project it can often be very difficult to jump from language to language without losing rhythm, thus a time consideration. Not to mention the stigma that many developers carry towards SQL being a second-class programming language.

While I certainly don't share this sentiment, and view SQL as a very powerful tool, the harsh reality is that many developers are very SQL deficient as a result, and resistant to refine these skills. This level of neglect opens the door for ORM.

For context here is a Ruby Active Record query from a recent project of mine. Magazine subscriptions serve as a join table between the Reader class, and the Magazine class:

class Reader < ActiveRecord::Base
    has_many :subscriptions
    has_many :magazines, through: :subscriptions

    def total_subscription_price
        self.subscriptions.sum(:price)
    end

end

// Here are the raw SQL queries being ran under the hood when .total_subscription_price is called on an instance of Reader:

SELECT  "readers".* FROM "readers" ORDER BY "readers"."id" ASC LIMIT ?
SELECT SUM("subscriptions"."price") FROM "subscriptions" WHERE "subscriptions"."reader_id" = ?

Abstraction

Going hand-in-hand with the comfort that ORM frameworks provide, is the idea of abstraction. A key concept of OOP, abstraction is the process of hiding all but the relevant data about an object in order to reduce complexity and increase efficiency. ORM offers a higher level of abstraction compared to SQL, making it often easier to accomplish your goals. ORM frameworks automate a lot of the heavy lifting, thus facilitating a less complex environment between the developer and the database.

We can humorously view ORM frameworks as a translator between Albert Einstein and an infant, in cases where the developer may not be very confident writing raw SQL.

Flexibility

One last advantage worth noting is the level of flexibility that ORM offers developers. Since ORM frameworks abstract the database, you are free to move from one system to the next. In other words, you aren't bound to one particular DBMS (database management system) and can make changes whenever you would like, since the ORM framework will automate compatibility.

The same is true for the model (logical structure of a database) itself. Since it is weekly bound to the rest of the application, you can also make changes as you please.

Limitations of ORMs

Of course ORM doesn't provide a one-size-fits-all solution to some of the considerations mentioned above. While it does offer some appetizing benefits, it is also plagued by some limitations as well.

Speed

In an ever-evolving digital world where the concept of delayed gratification is nearly extinct, speed and performance come second to none. While ORM frameworks can offer a great barrier from the drudgery of writing raw SQL, they are typically only optimal when implemented in smaller-scale applications. As projects and queries continue to progress, they slowly begin to expose the shadow of their facade. In high-volume, low-latency environments, ORM is probably better left uninvited.

Control

With raw SQL you are that much closer to the action. While this comes with a lot of responsibility, it also offers a higher degree of control. Being able to query your database with no middle-man means you are effectively in the driver seat. On certain occasions, a chauffeur can be nice, but ultimately you are at the mercy of their driving style (vendor lock-in), and unfortunately they can't always make that sharp right turn that you would have liked.

Abstraction

Wait I thought abstraction was an advantage?! Well in most cases it is! However, abstraction screens developers from what is really going on under the hood. This lack of visibility can create performance issues and make troubleshooting more challenging. If you are going to use an ORM framework it is still a good idea to familiarize yourself with what is happening behind the scenes, rather than following blindly.

Conclusion

If you're still trying to decide whether to implement ORM in your next project or not, I think the most important question to ask is the complexity of your scope. While ORM can be a great technique to make your life easier, by avoiding the dread of writing raw SQL queries, it certainly has limitations at scale; namely speed, performance, and visibility. So unless you're creating a small-scale application, I highly recommend becoming close buddies with the SQL-wizard in your office. If not, it may be time to brush up on it yourself!