[TonyAlicea10]

I’d say the most impactful thing is not to learn SQL, but set theory.

Well-written SQL is about thinking in sets. I cannot tell you how many poorly written procedural stored procedures I’ve replaced with a single performant SQL query over the years.

This is because the most impressive part of the SQL ecosystem is the DBMS engine’s query plan. Though, yes, you have to know how to influence it.

I find ORMs also tend to keep devs thinking procedurally.

Yes learn SQL! But don’t just learn the syntax. Learn the underlying mathematical models and ways of thinking that SQL supports implementing.

[Rendello]

I think I had a pretty good understanding of set theory through programming, and although I tried to get into the more mathematical side of it, I found most things to be 1. trivial (because I was used to thinking in lists, sets, hashmaps, etc.), or 2. irrelevant to me. The latter was a shame, because I've always liked the abstraction of math, but I couldn't help but feel I wasn't learning anything actionable when learning more about sets (though maybe I'm wrong).

What had a big impact on me was the relational model, specifically after reading Richard Fabian's Data-oriented Design book [1]. I had watched Mike Acton's famous Data-oriented Design talk [2], then Andrew Kelley's talk [3] where he explains speedups in the Zig compiler using DoD principles (largely using methods from Acton's talk), but Fabian's book tied these concepts to database normalization and the relational model.

Most DoD advice is very "exercise left to the reader", because it's about matching a specific problem, but using the relational model and considering your data's primary and foreign key relations can be really powerful. I just wish more of that power was exposed through regular programming language interfaces, rather than having to pull in and marshal data through a DB. I might have to try C# and Linq.

1. https://www.dataorienteddesign.com/dodbook/

2. https://www.youtube.com/watch?v=rX0ItVEVjHc

3. https://www.youtube.com/watch?v=IroPQ150F6c

[TonyAlicea10]

Relational model too, yes. But the biggest "aha" moments I've had mentoring devs on thinking in SQL came when they understood that the result of a query is itself a set. So you can join two selects, join that result with another select, then group on the whole thing.

Those kinds of patterns would often replace manual loops in stored procedures and opened up set theory-focused way of thinking. These patterns are made more performant and easier with good relational modeling, of course.