If you dove into a course like Rails for Zombies as your introduction to web development, or jumped right into a web framework with something called an object-relational mapper (or ORM), you may not have written any SQL. Not sure? If you were writing SQL, it would look like:
Instead, you may have written:
Let me break down what’s going on here — a zombie is an object that maps to the zombies table in the relational database (hence, ORM). This object has special powers (aka, functions) we can call on it, such as the “all” function, which fetches all the zombies by running the SQL I wrote above (the “select *” code).
Often, these ORMs allow for a more elegant way to fetch data from a database, rather than writing a big, long SQL query. So instead, you get to write beautiful code that’s much easier to read. For example, which of the following is more understandable?
Here, we’re finding a zombie named Joe, and asking for all his weapons. The equivalent in SQL might look like this:
The first one looks nicer, right? There are lots of reasons why using an ORM is pretty awesome that I don’t have time to dig into in this blog post, but there’s one big drawback. And because today we launched our new course, The Sequel to SQL, there’s no better time than now to dive into it.
Why Devs Need to Know SQL
When you use an ORM, you rarely have to write SQL, so people don’t spend much time learning or practicing it. This leads to a whole series of bad things, but the big ones are:
Poor Data Modeling — When you’re dealing with complex systems, you can easily have 100 tables. If these aren’t designed properly, you end up with lots of duplicate data and over-complicated systems.
Hundreds of SQL Queries — Developers often don’t keep in mind that ORMs may create hundreds of SQL queries that hammer the database and slow the site down.
Slow Queries — Often, developers will do something complex with the ORM that may generate a monster SQL query that could take 10-plus seconds to run. This is not going to help generate quick responses for our customers.
Low Data Integrity — Without the proper use of constraints on your database, your data can get messy and old. Projects that span years usually end up with records that never get cleaned up when they’re not needed anymore.
The solution here is to ensure every developer takes the time to fully understand the SQL language before they graduate to using an ORM. Understanding database table modeling, relationships, constraints, and joins will help developers avoid these pitfalls.
Ready to start learning SQL? Play through our new course, The Sequel to SQL, which covers a lot of the key topics — like aggregate functions, constraints, joins, and subqueries — you need to know to work with relational databases. New to databases? Don’t know what CRUD is? You’ll want to head over and play our Try SQL course first.