Why you should learn SQL instead of just using an ORM

Preface

I previously worked on an analytics team where we managed hundreds of millions of rows of data. I never actually did add everything up, but I wouldn’t be surprised to see the total over a billion rows. We put everything in PostgresSQL and wrote all of our queries out ourselves.

I have personal testimony that understanding other languages will actually make you better in the language of your choice. Love JavaScript? I promise you that you’ll understand and become a better JS dev by learning and writing in an OO language like C# or Java. Same with SQL. It’s such a drastically different language that by contrasting the two as you learn SQL, will bring a deeper understanding of both. Questions will rise that you never thought of until you started writing in a different language. “Oh JavaScript must just do that under-the-hood? Wait how does that work the same in JavaScript?

WTF is SQL?

The wikipedia answer is:

SQL (Structured Query Language) is a domain-specific language used in programming and designed for managing data held in a relational database management system, or for stream processing in a relational data stream management system. It is particularly useful in handling structured data, i.e. data incorporating relations among entities and variables.

To explain it even simpler, it’s the language used to work with data in databases. As wikipedia teaches us, it acts differently depending on the database you use it with (…domain-specific language…). Some aspects of the language change depending on if you are working with PostgrsSQL or Oracle.

WTF is an ORM?

ORM stands for Object-Relational-Mapper. These are tools designed to abstract away the pain of learning to write SQL by letting you write in your preferred language. For example, take a look at this SQL statement:

select user_handle from users where email = 'tyler@gmail.com';

Now what if you could achieve the exact same result but write it in the language of your choice?

Like JavaScript? Here ya go:

import SomeORM from 'some-orm-npm-pacakge'

const user = SomeORM('users')
  .select(['user_handle'])
  .where({ email: 'tyler@gmail.com' })

Looks cool right? Now you don’t need to understand all of the syntax around SQL and its pesky requirements.

Like everything, use the right tool for the job. Whether you want to use an ORM of your choice or query from your DB yourself, you are making tradeoffs ether way. Here are some pros and cons for both. You decide what you want to use.

Spoiler, I’ll end with my recommendation 😏

Pros

ORMs

  • Use the language of your choice. Look SQL is hard, trust me I get it. If you work primary in the frontend or just simply don’t ever query your data, you can easily forget the syntax. That’s understandable! A good ORM will have all of the complex SQL stuff like imports/exports, transactions, grouping data for you without you again, needing to worry about the syntax.
  • Switching between PostgresSQL and MYSQL? Don’t fret, a good ORM will handle most differences between the two syntaxes automatically.
  • ORMs can automatically tune your queries for you! With pure SQL, you need to understand what you are doing in order to optimize for performance.

SQL

  • The umbrella pro to vanilla SQL, which probably goes without saying, is you get absolute flexibility over your queries. That means you have complete control to performance tune your queries, get out edge case data, and debug as necessary. Abstraction is great, until a non-happy path problem arises and you are stuck surfing github issues and/or stack overflow.

Cons

ORM

  • Initial setup and configuration can take some time and learning. You also need to simply learn the API of the ORM as well. This is again especially true if you are working in a non-happy path environment.
  • While you don’t have to learn the syntax of SQL, you still have to learn how the flow of SQL works. When using an ORM the data doesn’t magically appear, you still need to understand CRUD statements and clauses.
  • Debuging, performance tuning, and pulling out complex data can be a trial and error process.

SQL

  • With great power comes great responsibility. Haha just kidding, but seriously, SQL is a wickedly powerful language. So understanding all of the requirements needed to pull out data can be overwhelming.
  • SQL syntax changes between databases. Built-in functions and specific operators are sometimes not universal. So if you jump between DBs, you’ll have to understand what works and what doesn’t work.

So what should I use!?

The blanket, cover all my bases answer is use what makes sense to you. ORMs generally have a smaller learning curve but are somewhat limited.

If you really want me to give you my opinion, its learn SQL. I know many don’t share my opinion on this but I think that your career path in the long run will benefit more by learning the language itself (fundamentals of the language). Abstractions have their place but they have a track record of constantly changing. Ie. handling breaking changes, fighting package managers, or just trying to keep up with the newest/shiniest/most hyped abstraction.

Fundamentals last longer.

Just the shear fact that you have to learn how SQL works anyways in order to even use a ORM, I’d say just take the extra time learn the syntax. I know of some pretty great resources out there that can help you out in that regard 👇👇👇👇👇

Additional Resources:

Share This:

I send out a newsletter... occasionally 🙂

If you like my content then you can sign up to be notified of upcoming stuff first. Most of my letters will be centered around frontend stuff, i.e JavaScript, CSS, React, testing stuff.. Though I'm also passionate about some soft skill stuff, interviews, SQL, and other backendy things.

No spam, I won't sell your info, and you can unsubscribe at any time.

Copyright © 2020 Tyler Clark