We stumbled across much the same thing building out a query layer of composable join clauses. In previous efforts at something similar, I've used CTEs, but found the ergonomics worse because the query layer had to differentiate between cte clauses and regular ones.
Skimming the original article, I didn't really understand why the author didn't discuss "WITH" CTEs (for SQL newbies, common table expressions, see https://modern-sql.com/feature/with ) as alternative composition mechanisms.
Or even SQL views. But your ergonomics comment makes sense to me.
guy i used to work with once said "you scared to rawdog sql or something" when talking about orms lmao. ive spent a good bit of time querying sql directly, to the point that even when im coding other stuff i actually kind of get his point. i highly prefer using the query language thats specifically specifically to query the database and idk if ill ever become an orm enjoyer
side note: man i hate how people write sql, drives me nuts how wild west it is syntax wise out in the world. i could wax poetic on how its stinky but when it comes to sql, people are already locked in on how they write sql so they are absolutely unwilling to entertain new approaches there. im literally the only one dying on this hill but using caps all over the place when syntax highlighting exists in 2026 is wild. sql might be the one place in the universe where commas on the left in your select statement makes sense, `on` clause join keys deserve to be on the next line and tabbed in under the thing they join to otherwise you're stuffing join tablename alias on alias.id = b.id (this wouldnt be such an eyesore but people are very not-verbose with their table aliases, so eye scanning tablename/alias/join keys kinda sux)
We stumbled across much the same thing building out a query layer of composable join clauses. In previous efforts at something similar, I've used CTEs, but found the ergonomics worse because the query layer had to differentiate between cte clauses and regular ones.
You raise a good point.
Skimming the original article, I didn't really understand why the author didn't discuss "WITH" CTEs (for SQL newbies, common table expressions, see https://modern-sql.com/feature/with ) as alternative composition mechanisms.
Or even SQL views. But your ergonomics comment makes sense to me.
guy i used to work with once said "you scared to rawdog sql or something" when talking about orms lmao. ive spent a good bit of time querying sql directly, to the point that even when im coding other stuff i actually kind of get his point. i highly prefer using the query language thats specifically specifically to query the database and idk if ill ever become an orm enjoyer
side note: man i hate how people write sql, drives me nuts how wild west it is syntax wise out in the world. i could wax poetic on how its stinky but when it comes to sql, people are already locked in on how they write sql so they are absolutely unwilling to entertain new approaches there. im literally the only one dying on this hill but using caps all over the place when syntax highlighting exists in 2026 is wild. sql might be the one place in the universe where commas on the left in your select statement makes sense, `on` clause join keys deserve to be on the next line and tabbed in under the thing they join to otherwise you're stuffing join tablename alias on alias.id = b.id (this wouldnt be such an eyesore but people are very not-verbose with their table aliases, so eye scanning tablename/alias/join keys kinda sux)