If you’re a developer, there’s a good chance that you’ve met the acronym “ORM.”
“ORM” stands for Object Relational Mapping, and it’s software that bridges the object-oriented format of much modern program code with a database.
My introduction to ORMs took place circa 2016 when, as the leader of a newly-formed development team, I started investigating PHP frameworks for use at the City of Chattanooga. Pretty much every PHP framework (everyone I’ve seen anyway) comes with an ORM.
A trusted colleague and I debated pros and cons over the years, which is a testament to our ability to debate… since we were both on the same side (we mostly hated the damn things from the get-go). Nevertheless, I always felt like, “maybe I’m just not seeing it, I should keep trying to find the merits.”
Pros and Cons
Here is a list of advantages to using an ORM (with my notes added) that I borrowed from freeCodeCamp:
- It speeds up development time for teams. (If you a) know the ORM like the back of your hand but don’t know SQL. KK)
- Decreases the cost of development. (If you a) know the ORM like the back of your hand but don’t know SQL. KK)
- Handles the logic required to interact with databases. (If you know SQL, you can just use it… it’s why SQL was invented. KK)
- Improves security. ORM tools are built to eliminate the possibility of SQL injection attacks. (Or you can just sanitize all your inputs which YOU SHOULD BE DOING ANYWAY. KK)
- You write less code when using ORM tools than with SQL. (So you save a few lines when you write once (as you should) each specific query. Is that worth loading thousands of lines of database-obfuscation? KK)
The same article lists the following disadvantages:
- Learning how to use ORM tools can be time consuming.
- They are likely not going to perform better when very complex queries are involved.
- ORMs are generally slower than using SQL.
So… developers could:
- spend a lot of time learning ORM;
- spend the necessary time to learn SQL and something about databases.
I’m sure you already know where I’m headed with this: I’m officially giving up on trying to find value in ORMs. But there’s more to it than that.
Databases are cool, and you should meet one or two.
I’ve become a fan of OOP over the years (although I’m sure there are rules that I break because I don’t even know these exist!) and one of the things that kept me trying to love ORMs was the fact that they OOP’ed the DB stuff.
But let’s take a step back for a second. Virtually every application stores data, and if that data is more than just something like a profile or a game-save, there’s a pretty decent chance that there’s a database involved. Doesn’t it seem like there’s some merit to knowing how to talk to the database in its native language (i.e. SQL)? I’m not saying every developer needs the skills of a full-fledged DBA (database administrator) but intentionally fostering separation between the developer and something as intimately important that the database their application is using seems, to me, less than productive. Especially since ORMs take a ton of time to learn (especially if the documentation is poor), adds overhead, and just doesn’t really bring anything great to the table to give itself value.
There may be an ORM out there that’s so great it would change my mind (if you know of one, please comment so I can check it out!) Specifically I mean one that doesn’t simply just make you write the same thing (code that tells the database what you want) using their syntax which then has to then be translated into something that the database can understand… so that you, hopefully, can get what you wanted when you started.
The Bottom Line
My advice to newer developers? Skip the ORM, at least to begin with. Learn to connect your code directly to the database, learn some SQL, and learn to secure your code properly. If you want to investigate ORMs later, that’s great… I investigate tools all the time and even if I don’t use them, I learn from the snooping. I’m not saying that ORMs are bad (well, okay, maybe I am, kinda) …I’m just saying learn SQL, learn some of the basics of database terminology and functionality, and learn a few things like how relational and document databases differ (and when to choose one over the other).