I just think that at the end of the day, for any moderately complex system under non-trivial load, the idea that you want to "hide the complexity of SQL" from the service developer is an absolutely flawed premise.
I disagree. I've used many ORMs in my ~20 years, and I've architected and designed several hugely complex systems under non-trivial load.
There are really two things I want to put out there:
1) My opinion is that about 90% of your standard, day-to-day queries work just fine in a good ORM. The developer _should_ know enough about the DB schema and SQL to handle the other 10%. (In our 10 y/o enterprise software, the only queries we really drop down into SQL for are complex windowed reporting queries.)
2) Eloquent ORM is... different. It's probably the best I've seen. I wish it existed in other languages. Sequelize, which may be the "best" in the JS ecosystem, doesn't hold a candle to Eloquent, IMO.
That's not really the point of ORMs though. It's map your data objects in code to your entitled in your relational database. That it comes with a SQL builder is just a necessity in order for the mapping to be done by the ORM. You can still write raw sql with most ORMs, but then you won't get the mapping which is the point. In some cases you will need to do that and that's fine. Hiding complex SQL isn't the goal
> That it comes with a SQL builder is just a necessity in order for the mapping to be done by the ORM.
That's only true if you need the "relational" part of an ORM - mapping a flat list of values onto a structure of related objects. If you only need to map a flat list of values onto a single object's fields, you don't need a query builder.
It's not just about hiding the complexity of SQL. You also get flexibility you don't have when writing SQL directly. For example, our laravel app uses pgsql in production environments but uses sqlite in our CI environment. We also migrated off of mysql which consisted only of changing a configuration value and verifying no issues by running tests
> I still write and think in SQL, but don't have to write queries as strings.
Why is that a benefit though? Why would I rather learn some custom query builder-specific DSL when SQL is at least mostly standardized pretty much everywhere. The use of template strings in JS can get rid of all the problems of just plain string concatenation for SQL (e.g. it can prevent SQL injection, enable safe dynamic queries, etc.)
There are really two things I want to put out there:
1) My opinion is that about 90% of your standard, day-to-day queries work just fine in a good ORM. The developer _should_ know enough about the DB schema and SQL to handle the other 10%. (In our 10 y/o enterprise software, the only queries we really drop down into SQL for are complex windowed reporting queries.)
2) Eloquent ORM is... different. It's probably the best I've seen. I wish it existed in other languages. Sequelize, which may be the "best" in the JS ecosystem, doesn't hold a candle to Eloquent, IMO.