+1 for these three points.

But I'm really surprised every time people tell me they look at the schema as defined into the ORM instead of at the table in the database.

I'm really jaw dropped the few times I know somebody doesn't even know SQL, only the ORM. Maybe they look at it as if it were the reaction of somebody that thinks you must know assembly if you want to program Ruby, Python or Node (I don't.) Still, if you work with a database you must know it's internal language, SQL or NoSQL. Your going to need it or build a mess.

And involving a DBA early in the project can make your database at least twice as fast, with the right schema and the right queries. Then you translate that into the ORM you want to use.

Woah, who are you interacting with that not knowing SQL is rare?

In my experience, nearly no one knows SQL, and the attitude seems to be that learning it at all is a waste of mental bandwidth.

On the other hand, I wonder if knowing none at all is better than knowing a little.

Wow, I've never met a developer that didn't know SQL.

Even 1 year "learn programming fast" courses here in Uruguay have at least the basics. OTOH, Javascript is not taught in many courses so YMMV...

I expect that everybody with a degree knows SQL and I'm realizing that I could be wrong. Maybe sometimes I'm the only one in the room that knows it. I'll check it next time I'm at a technical event leaning on the backend side.

I haven't written very much SQL in my career, there is quite a lot of development that doesn't use it.

On the other hand learning javascript frameworks... /s

I find that jOOQ (java) solves all that for me.

Very happy to not have and ORM on our stack for many years.

I believe that the interaction with the database is just about the most important part of code that you need to rely on. We have had messy data written to the database due to misused or misconfigured ORM (perfomance issues, bad orphan handling, session state problems, overflown sequences, to list a few) and decided that we should not rely on all devs touching that code to be experts in the ORM api to avoid the pitfalls, we rather our devs be expert in SQL.

Never had any of them complain about mapping using something like jOOQ. Type checking and composability are also built in.

Yep, MyBatis is also another nice alternative.

DALs can be easily written with libraries like MyBatis, jOOQ, Dapper, ....

Just because we are using SQL doesn't mean we have to do the mapping fully manual.

I use jOOQ - I like the benefits of having the static type checking but the ease of expressing with a SQL like DSL.

Plus it plays very nicely with kotlin :)