I just finished a formal database class in my MBA program. I signed up expecting a review and got a reorganization.
Some context. I've been writing SQL for about two years, all of it self-taught: documentation, practice databases, queries against whatever data I could get my hands on. Before that, a decade in beverage operations and finance, where the database was a workbook and the query language was whatever chain of formulas survived the quarter. So I walked into the class already able to write most of what the syllabus covered.
The class still gave me three things the self-taught path hadn't.
Vocabulary, first. I had been doing things I had no names for. I knew two tables shouldn't store the same fact twice; I didn't know the word normalization, or that the forms are numbered, or that my instinct had a test I could apply instead of a feeling. Naming things sounds like a small gain until you try to read a vendor's documentation or ask a database engineer a precise question. Shared words are most of what makes either possible.
Second, the set theory framing. Self-taught SQL tends to be learned as incantation: this clause, then that clause, and the rows come out right. The class taught queries as operations on sets, with the clauses as predicates and projections over them. The same statements I'd been writing for two years changed shape. Problems I used to solve by trial and error became problems I could reason about before touching the keyboard.
Third, modeling discipline. I had always started with the table and discovered its problems later. The class starts with the model: entities, relationships, what a row means, and only then the DDL. It is slower and it is correct, and I now understand why every painful dataset I've inherited was painful. Someone skipped that step.
What the class could not teach is what it costs to be wrong. Course datasets are clean, the questions have answers in the back, and the worst outcome of a bad query is a lost point. For ten years my numbers went into decks and meetings where people committed money, scheduled production, and signed contracts on the strength of them. That experience taught a different syllabus: which mistakes are quiet, which numbers deserve suspicion, what it feels like to find your own error after the decision was made. There is no course for that. There is only shipping numbers people act on, and living with the ones that were wrong.
I've written beginner SQL material before; this site's archive has a full syntax walk-through from last year. The syntax explanations hold up. The pacing is what I'd change: ten patient posts for material that deserves one fast one, and nothing at all about the part that actually took me years.
So that's the plan for the fall. A new series, Production SQL, starting next month. The first post covers the entire working syntax in an afternoon, because that is roughly what it takes. The rest cover what the syntax can't tell you: why your total is wrong, what a NULL does to an average, how to prove a number before someone acts on it.
— Lo