[bartread]

Yeah, exactly. I think the best approach is always to know SQL and know the ORM.

Most of the time you’ll be able to simply use the ORM, but every so often you’ll inevitably come up against a situation where a custom query gets the job done better, and you’ll still get the benefits of deserialising to objects that the ORM offers.

[datsci_est_2015]

> you’ll inevitably come up against a situation where a custom query gets the job done better

In my experience, these are typically best turned into views (or materialized views), because they represent some fundamental relationship or property within the data that’s useful to be able to quickly reference or query directly against. KPI aggregates, for example.

[simondotau]

As long as you restrict yourself to an ORM-compatible schema, you are restricting the power of SQL available to you. Learning SQL properly means learning to model your data correctly, and this usually makes ORMs a non-starter.

Without an ORM you have to write a bit more boilerplate code to interact with the database. But by taking advantage of the power of your database engine, you could potentially avoid writing huge amounts of data manipulation logic. In my experience, an ORM is more of a code amplifier than a code simplifier.

[bartread]

All of this depends on the problems you’re solving though. There is no one size fits all approach to database development.

[simondotau]

Generally speaking if an ORM is a good fit, the thing you're doing probably isn't database development, it's application state management disguised as database development.

[win311fwg]

ORM is compatible with any schema, but perhaps you are thinking of something like the active record pattern?