It's critical to have a good understanding of SQL, but once you do, ORMs with a functional syntax solve this problem for many of us. I know it's not possible for some people to use ORMs as they can't risk the ORM making a performance mistake, but I think the solution is to improve ORMs to the point that writing raw SQL is akin to writing assembly instead of using a higher level language.

That said, we're not there yet. Using an ORM in 2017 without understanding what SQL you want it to produce IS NOT OKAY. Please learn SQL if you're going to use an ORM, and understand the SQL you are producing with the ORM.

Summed up, if you can, use an ORM to solve this problem.

I think the solution is to upgrade SQL the language. There's a very low complexity threshold after which you have to trade readability/composability for decent performance (in other words, there are a lot of cases where a human can notice a permissible optimization, but a database can't because it might break correctness for some odd edge case). We're solving that problem with programming languages (notably Rust); I'm not convinced that there's something inherently different about relational databases.

Project M36 is a database that implements a relational model and corresponding query language (TutorialD) based on (among other things) the ideas from Date and Darwen's Third Manifesto. TutorialD solves many of the problems present in SQL, especially around composability.

https://github.com/agentm/project-m36