Learn SQL, dammit! - Gun.io

The following is a guest post by Michael Herman, author of the Real Python for the Web course. He is also the co-founder of Real Python and Inetvators, and the founder of Starter Financial Model. He loves running, cooking, and all things Excel. Python is his tool of choice, of course. He blogs at mherman.org.

When I began creating my own course, Real Python for the Web, I knew that I was surrounded by people to help with the process. My best friend is one of the best Python programmers I know. He challenged me to think beyond Python and programming, to reconsider my initial assumptions and teaching methods, to take it further. Most of his remarks I agreed with, except for his main criticism:

Why are you teaching SQL?

He didn’t understand this, and I was determined to prove him wrong. As a backend programmer he deals with relational databases management systems (RDMS) every day. Yet he does not know enough SQL to even display all data from a table. Like most web developers he uses an ORM to design an application’s model.

I admit: At first glance it’s tempting to rely solely on an ORM to develop and interact with a RDMS:

• The code is much quicker to write and easier to understand, because you bypass that “unnecessary” SQL code that often needs to be written over and over when first developing your model. ORM’s objectify much of the actual development, allowing for code generation from a “scaffolding” or “boilerplate” pattern.
  

• If your only concern is rapid web development, ORM’s are perfect. You get your first iteration/prototype up quick, and then don’t have to worry about all of the trivial details until later.
  

Once that model is up and your app is starting to grow, an ORM is inadequate to handle much interaction with a RDMS on its own. SQL is needed. No matter how much you try to avoid using SQL, you will eventually come back to it once your application gets big enough.

Here are 4 reasons we need SQL:

Look at any ORM documentation. Most are littered with indirect references indirect references to SQL. You need to understand how SQL works in order to grasp these references. This begs the question: How much SQL does one need to learn in order to adequately understand the documentation? Think about it, though: it’s absurd that you would even need to learn any SQL at all! The very nature of an ORM is to bypass SQL. But now you have to learn both syntaxes! Adding more time and more work to your plate.ORM as a replacement for actual SQL queries will not take you the distance. Good luck with any sort of complex queries. (Really anything beyond a simple SELECT query.) It is difficult and usually requires more code than a basic SQL join. ORM is better for many of the CRUD functions, but a terrible replacement for SQL when it comes to querying or reporting.Not everything can, or should, be represented by objects. SQL uses relational logic for nearly everything, so there will be an object-relational mismatch. And when you get down to the nitty-gritty levels of relational database interaction, ORMs are just not feasible alternatives. They work great at a high-level, but are not meant for all interaction. This leads them to being used in many situations in which they were not originally designed for.In my course, I introduced CRUD through SQL. It’s simple, smooth, and a perfect segue into HTTP methods. Why not learn enough SQL to grasp CRUD if it’s going to be taught in the first place – but that’s a separate argument altogether?

Fortunately, there are many solutions. Above all, remember that there is no one-size-fits all solution.

• Learn SQL from the start if you use a relational database and are a beginner to web development. You will save yourself much pain in the long run trying to debug ORM code without understanding the underlying SQL syntax.
  

• Use an ORM to get an app up quick and dirty, so you can focus on the key features of your application, and then when you’re ready to build out a second iteration, switch over to SQL. You will simply have better control and SQL is faster (because an ORM is an abstraction layer on top of SQL) and, frankly, what’s better than being able to design a model to meet your application’s needs?
  

• Use an object-related database along with an ORM and forget about SQL altogether, which is probably the best solution altogether.
  

• Or you can design your own solution.
  

After all of this my best friend now agrees with me, SQL should be taught. I even ended up teaching him SQL for a job interview.

Comments