Comment by perl4ever

"SQL is extremely expressive, it's almost impossible to build something that cannot be expressed in an SQL query."

That's kind of orthogonal to what I think is the issue being expressed here.

SQL can do many things; the problems tend to be when a query doesn't perform consistently and predictably. There's always a balance to be struck between communicating what is to be done, and how it is to be done, and SQL leaves so much of the "how" out that the query interpreter/optimizer is incredibly sophisticated and does a fantastic amount of work and yet frequently gets things spectacularly wrong, maybe due to misconfiguration and maybe due to fundamental limitations.

Obviously more information on how to do something is not always better; otherwise we'd be using assembler. But there is a balance.

Experts tend to say "write everything in one query, and if it doesn't work, fix the configuration of your database" which is not helpful given the division of responsibilities in any company. But they will say that because they are devoted to the idea that all that expressiveness is good for something.