SQL is pretty shitty language to write modular, reusable and easy to read code.
6 comments
ORMs often end up defining their own domain-specific language which is neither SQL nor the language itself, so they don't really solve that problem except in the simplest cases.
With the big exception of Entity Framework which relies on LINQ.
It's easy to read SQL code as long as the person writing the query doesn't resort to "hack" the planner.
Now to make that reusable....That's another beast and most often will defeat the purpose of writing pure SQL in the first place, let's put a OR there, let's call several queries, let's screw the data model.
It solves a hard problem. For example, it completely insulates the sender from the fact that his transaction is just one among many others.
No, database servers solve that problem. That the unnecessarily COBOL-like SQL ended up being the primary interface to them is simply an unfortunate accident of history.
There have to be some limitations on the language for this to work. For example, there must be no way to specify a neverending loop or to lock something and forget to unlock, an so on.