I have been a business analyst for four years and I could always do the easy 80 percent of SQL: joins, GROUP BY, a WHERE clause, the occasional CASE statement. But the moment a question needed a window function, I would quietly export a CSV and finish the job in a spreadsheet like a coward. ROW_NUMBER felt like a magic word that other, realer analysts knew and I did not. And I was not learning it from documentation, because documentation explains patterns with toy tables called 'foo' and 'bar' and three rows of made-up data that bear no resemblance to the gnarly 14-table mess I actually work in. The abstraction never crossed the gap into my real job.
The accidental study method
I started using the Write a SQL Query from a Plain-English Business Question prompt for real work — not to learn, just to ship — and a funny thing happened on the way to shipping. Every single time it handed back a query that used a pattern I did not recognize, I would read the plain-English explanation it includes, and then I would ask it a follow-up in the same thread: 'explain the ROW_NUMBER part like I'm brand new to window functions, using these exact columns.' Because the explanation was tied to MY query, on MY tables, answering MY actual question, it stuck in a way no tutorial ever had. Three or four queries a week for a month, and I had quietly absorbed five patterns I had dodged for years.
I want to be clear that I did not set out to study. I set out to avoid filing a ticket. The learning was a side effect of reading the explanation every time instead of blindly copy-pasting, which is a habit this prompt makes easy because the explanation is right there, in order, next to the code.
The five that finally clicked
- ROW_NUMBER() OVER (PARTITION BY ...) — deduping and grabbing the single most-recent row per user, which I used to fake with a messy GROUP BY and a join back to the original table.
- LAG() and LEAD() — comparing each row to the previous or next one in a time series, so day-over-day deltas no longer need an ugly self-join.
- CROSS JOIN LATERAL (Postgres) — applying a subquery per row, like 'the top 3 events per user' computed in a single pass instead of a loop in my head.
- Recursive CTEs — walking hierarchical data like a category tree or an org chart, which I had genuinely believed was just not a thing SQL could do.
- FILTER (WHERE ...) on an aggregate — conditional counts that read cleanly, instead of stacking CASE WHEN expressions inside a SUM and squinting at the parentheses.
Why a working example beats a tutorial
The difference is that I was never learning a pattern in the abstract. I was learning why THIS query, for the retention report I actually had to ship by Thursday, needed ROW_NUMBER instead of a naive DISTINCT that would have silently kept the wrong row. Claude Opus 4.8 keeps the explanation specific to the query it just wrote, with my real column names in it, so I was reverse-engineering working code rather than reading a definition and praying it transferred to my schema. It transferred, because there was no gap to transfer across — the example was my own data the whole time.
The honest caveat
I am not going to pretend I can write a recursive CTE from a blank editor at full speed. I cannot, yet, and I might never need to. But I can now read one and know exactly what it does, recognize from the shape of a question when one is called for, and — most importantly — verify that the query the AI gave me is actually doing what I think it is doing. That last part matters far more than my ego does, because a wrong window function does not throw an error. It silently poisons a dashboard for weeks, and you find out when someone important asks why two numbers that should match do not. Fewer wrong-data incidents in my reports is the real, unglamorous win here.
If you have been avoiding the scary half of SQL, treat this prompt as a tutor that grades its own homework out loud, on your data, every time you ask. Grab the Write a SQL Query from a Plain-English Business Question prompt on Prompt Dock, run it on a real question you actually have, and read the explanation like a short lesson instead of skipping to the code. And when a query comes back correct but slow, hand the whole thing to the Explain a Slow Query and Suggest an Index Strategy prompt and learn the performance half of SQL the same way — one real query at a time.