A beginners guide to thinking in SQL
I love this guide and will probably steal ideas from it when writing my own SQL tutorials. That said, I don&#x27;t think SQL is <i>that</i> hard to read compared to other computer languages, at least for non-programmers.<p>I say this as someone who learned object-oriented programming far before I learned about SQL or its declarative model. SQL was &quot;hard&quot; for me because the declarative style is so functionally different than OOP, and to this day I still haven&#x27;t ventured to figure out the SQL equivalents of functions, variables, and other mainstays of general programming; I&#x27;m satisfied with using a scripting glue language like Python to automate simple SQL SELECT statements.<p>But I love teaching SQL to non-programmers. You can do a lot of important real-world things with it without having to jump deep into the logical puzzles of &quot;regular&quot; programming. By &quot;deep&quot;, I mean things like for-loops; it never fails to surprise me how befuddled beginners are about how for-loops work -- not just the syntax, but the concept of a &quot;block&quot; of code, that for-loops can exist inside of for-loops...or more fundamentally, you can run more than one line of code inside a for-loop.<p>With SQL, you don&#x27;t have to worry about any of that. You simply declare what columns you want from a table, what values to filter by, and optionally, how to aggregate it or join it with another table -- concepts that have much clearer analogies to everyday thinking about information (or, at least spreadsheets).<p>SQL gets complicated when you try to do complicated things. In the OP&#x27;s opening query, there&#x27;s a joining of three tables. But without reading it closely, I can already kind of describe the real-world information-need that it fulfills: List the people who have borrowed books that have been borrowed <i>something something</i> to do with `stock`. If I spent a few more minutes, I could figure out what the fuck that subquery,  `stock &gt; (SELECT avg(stock) FROM books)` is all about, but the difficulty there is just my ignorance of the domain and&#x2F;or particular conventions in this hypothetical problem. If I, or even the average novice, wrote this query line-by-line, its purpose would not be so opaque (as writings rarely are to their own authors). The point is that it&#x27;s much easier for a beginner to author their own SQL without fucking things up in the way you can easily do so with even just a for-loop. I can&#x27;t imagine that the Python or Ruby equivalent would be nearly as clear as this SQL statement, even for a far simpler kind of join.<p>My main complaint about SQL is that it seems more logical that the `FROM` clause should come before the `SELECT` statement. Though my initial guess is that that hampers the declarative-clarity of the statement when `JOINS` are involved.<p>edit: If I could make one suggestion to the submitted article, it would be that the first &quot;Simple Query&quot; is not simple at all:<p><pre><code>     SELECT bookid AS &quot;id&quot;, title
     FROM books
     WHERE author=&#x27;Dan Brown&#x27;;
</code></pre>
I&#x27;d argue that this is a simpler statement, and one in which the results are immediately recognizable to every spreadsheet user:<p><pre><code>     SELECT * FROM books;

</code></pre>
The default behavior of Excel is to show all columns of a data file. When you get more advanced as a SQL user (and more advanced in understanding the fundamentals of computation), <i>then</i> you start being selective about SELECT and realizing that, as an end user (nevermind the cost of computation), it&#x27;s not always ideal to see everything by default:<p><pre><code>     SELECT title FROM books;</code></pre>