Me too. Hours and hours of typing...then "RUN". I had a computer for about a year with no tape drive to store anything I typed. My Mom used to do me a favour and shut my computer off...thus losing all my work. Good times.
I started my IT career in the late '80s...and the buzz of the day was SQL. All the money those days (consulting, I mean) was for dBase. But the limits were becoming obvious (scale, mostly) and relational db's were moving rapidly. Yep, when Oracle was just an RDBMS. To learn SQL... well, hit the library. Lots of boring stuff on "relational calculus", but nothing I perceived as valuable. I found Maier's book...and while it had a lot of math, there was enough practical content that the lights came on for me. After that, I found books from E.F. Codd and Chris Date...wonderful! If you want to nerd out on this stuff, find the more recent works by Chris Date. I recall having many beers over null. And wacky joins. I haven't had to write SQL for pay in years...but for me, SQL and RDBMS are a wonderful diversion on the occasion I'm asked to unravel an issue. For some reason, the relational model still makes sense to me...and I don't know if it is because it's the first formal model I worked with, or of it's intrinsic value. Perhaps you never forget your first love. Anyhow, my advice to people digging into this, is to install (or get access to) a reasonably complete RDBMS, and create/populate a few tables and attempt to predict what your SQL will return. This is a key skill. I see so many devs writing queries and testing them... and watching what comes back and then (somehow) thinking they've got it right. Sure, with a few dozen rows...but try that on several million records. Nope. At scale, you must understand the relational model in general, AND you must profile the RDBMS you are running by experimentation to see exactly how it behaves... especially around nulls, default sort orders, and joins. Not all RDBMS behave the same way... and this will surprise most.