The typical language people use is imperative language where you state how to do something, while sql is a declarative language where you say what you want.
Since we are in the world of analogies, using an ORM is like taking a shovel and using it as a prop (without speaking) to explain excavator operator where to dig, how deep, how wide, what things to avoid etc. Except querying a database can be much more complicated. You might be successful with some simple tasks, but it will fall flat on more advanced things.
Anyway perhaps if databases would expose an interface and allowed you to directly write a query plan then that wouldn't be so bad? But then many people would complain that you need to know a lot ot use it, and also based on data your plan for the same data might need to be different to be fast.
Used to do this by replacing slow queries with a dozen joins with stored procedures,insert/update/delete triggers, materialized views.
The mindset was correctness and validity of a detailed and interrelated collection of known facts, at rest on disk.
Merging 2 of these, say when an insurance Corp buys a competitor, took detailed and painstaking effort by people with both the domain and systems knowledge.
It's very different now,with Json doc stores, where in 5 years time noone will know what timezone that happened in, or if this person is that person with different name because of lossy utf8->ASCII .
OK, I was thinking the shovel gets you closer to the dirt and you can ‘manually’ choose where to specifically dig, or not dig.
Whereas, the mini-ex is a complex hydraulic machine requiring regular maintenance and an operator that knows how to use the controls, and a fuel source. Lots of dependencies.
There was a youtube video of a group of men using shovels cooperatively to ‘throw’ cement:
Well, LINQ is special, it is a language that is similar to SQL that's inside of another language. Such code then is translated to SQL. The language is still not SQL but SQL-like and is incomplete, for example you can't do CTE in it.
