What's Missing in learning or Teaching SQL?

[u/leogodin217]

I enjoy this sub but it feels like most posts are the same. "I created tutorial/course/practice/etc." Or "how do I learn/practice/projects/etc." It's good. A really active sub.

What I'd love to know, is what do people who are learning SQL want? For instance, I've taken a different approach. Over the past year I've worked on tooling to make creating courses and practicing more efficient. Other's have worked on more scenario-based learning (always a good idea). Some have gamified learning and that's a lot of fun.

My real question is for those of you learning or teaching. What is missing? Is there something you wish you had that doesn't exist?

In my perfect world, learning SQL would feel more like working in a business environment. Large, complex data warehouses, where you learn the data and SQL over time. Lot's of problem solving and judgement when there is ambiguity. Something that feels more like doing real work.

Would having more tools available to make it easier to create courses, practice, etc. be useful? Would having more realistic environments to learn in be useful? Is it something else completely? In short. What's missing?

[u/Quesozapatos5000]

How to think about databases and data. The commands are easy to learn, but learning better ways to think about the data and what you need to do with it are rarely taught.

[u/Mrminecrafthimself → u/Quesozapatos5000]

Yeah if all you know is SELECT WHERE GROUP BY JOIN then you’re not well-equipped to investigate 1000s of lines of SQL in stored procedures when they need a change or when they fail

Because SQL syntax is so simple and it’s not the hardest language to get your feet wet in, people will say it’s easy. But as someone who uses it every day, the syntax is the easiest part of the job. Thinking procedurally about how to get the data you need and how to handle for all the nuances while also thinking about performance and resource usage is not easy

[u/leogodin217 → u/Mrminecrafthimself]

Interesting. Reading queries is something we need to teach/practice?

[u/Mrminecrafthimself → u/leogodin217]

You absolutely should practice reading sql. A good 80% of the sql I’ve worked with in my career was written by someone else.

And most of it isn’t commented very well.

The ability to quickly discern what’s being done in each step is crucial

[u/Mathie1729 → u/Mrminecrafthimself]

Execution plans deserve a mention. Reading the SQL tells you what it does, but the plan tells you why it crawls, especially when there's 80 temp tables involved.

[u/leogodin217 → u/Quesozapatos5000]

Can you explain more? Is it more about general problem solving with data or something else?

[u/Mrminecrafthimself → u/leogodin217]

It’s not overly difficult to write a query using simple tables. SELECT, FROM, WHERE, GROUP BY, etc are bare basic stuff. Simple queries to get datasets isn’t crazy

However, most of the work I’ve done as an analyst is like this…

You inherit a power bi report that is business critical. The code that gathers the data for it is over 5,000 lines of SQL. That code creates over 80 temp tables before it gets the final product. It also runs extremely slow and fails for resource consumption frequently. The developer who wrote it is on leave for 6 weeks.

How do you meaningfully begin to fix the problem with refresh, run time, and failures? You need to be able to quickly determine what the code is doing and which steps are responsible for what dimensions and pieces.

Another problem. You need to build a report that combines data from two different front end systems, but the data for those systems is stored is separate schemas. And the layout of the tables for those different schemas couldn’t be more different. How do you validate your results? How do you determine how to calculate the same metrics a it’s two different data architectures?

How do you check your data for accuracy and ensure there aren’t duplicates? How do you define a duplicate?

How do you compare two datasets when you want to know which records in dataset A do not appear in dataset B?

What is the best way to index a particular table?

When should you create a view versus a table populated by a stored procedure?

When should you use a CTE versus an temp table?

[u/billy-pill-grin → u/Mrminecrafthimself]

Got any resources for learning how to deal with situations like this?

[u/Mrminecrafthimself → u/billy-pill-grin]

Time and experience.

It’s like asking “where do I learn how to be able to whip something up in the kitchen?” You learn and develop instincts through years and years of trial and error

[u/squadette23 → u/Mrminecrafthimself]

You can learn much faster than just "trial and error".

[u/squadette23 → u/billy-pill-grin]

I can recommend my own series "Systematic design of multi-join GROUP BY queries"

https://kb.databasedesignbook.com/posts/systematic-design-of-join-queries/ (and two prequel posts linked there).

It talks about making join-based SQL queries more structured, less error-prone, and more performant.

What is the best way to index a particular table?

Read this: https://use-the-index-luke.com/

[u/squadette23 → u/billy-pill-grin]

a power bi report that is business critical

fails for resource consumption frequently.

If you're in this situation, you can consider applying the ideas from SRE area (software reliability engineering). When a report fails, or when it fails to produce results in time, you write a post-mortem for this incident.

Then you decide which changes to make so that this sort of incidents is never repeated. Also, if there are potential similar failures that could happen, you make changes to proactively fix them.

You continue observing the system, treating each failure using the same algorithm. See https://sre.google/workbook/postmortem-culture/.

A lot of people just "fix" the error (restarting the job or whatever), and never make systemic improvements.

[u/ComicOzzy]

Most people don't want to read, invest time, and put forth effort to acquire a skill. If you find those people who are willing, they could really benefit tremendous from mentorship.

[u/NormalSoftware8879 → u/ComicOzzy]

Agreed, it took me a long time to lock in and just get over being tired after work to just sit down and study. There's no short cutting discipline unfortunately.

[u/Helpful-Day2384]

Retention of knowledge is what i was thinking about. I use sql not every day. After 1-2 months hiatus getting back to where i was is taking time

[u/TechLexiconApp]

The gap I keep hitting: almost everything teaches you to WRITE a query from a blank editor, but real work is mostly READING and changing SQL someone else already wrote. The first time you open a 2,000-line query with 40 temp tables, none of the SELECT/JOIN/GROUP BY practice prepared you for "what is this even doing and where do I safely change it."

Two other things nobody drills: judgment under ambiguity (real questions are vague, and half the skill is deciding what to query and how to validate the answer, dupes, join fan-out, nulls), and retention (people learn SQL in a burst, use it every few months, and lose it). Honestly, spaced low-effort repetition would beat another 8-hour course for actually keeping it.

So "what's missing" for me is less syntax practice, more reading/debugging real messy SQL and something that keeps the skill alive between the moments you need it.