[loldot_]

What I've found being the problem with this approach is that sql does not lend itself very well to composability. Sure, you can make functions, views and stored procedures and compose them. But when you start actually composing queries of these parts the could lead to different execution plans having wildly different performance characteristics.

Also tooling around SQL, i.e. refactoring tools and debuggers, is not great - if even available at all.

[somurzakov]

sql is not a code, like c#, you dont debug it, you inspect results, or inspect execution plan/traces.

how would you debug HTML, for example? Open it in browser, right? same for sql: run it and see if it works as you wanted

same goes for composability: you can compose SQL same way you can compose HTML, but you still need to understand the big picture

explicit control flow in SQL (cursors, for loops and stuff) is absolutely an antipattern. You need to think in terms of relational algebra and functional programming in order to write clean SQL