[jasfi]

ORMs are useful when what you want to do matches their expressiveness. For example when I just want to get a record by its primary key. They have their limits, many times when doing complex reports. For that, most ORMs provide a raw SQL function. So just use the right tool for the job.

Stored procedures for business logic can be great for performance when they replace queries/mutations called thousands+ times.

[blagie]

ORMs are nice for "Hello World," and hit a brick wall later.

I don't mind them for simple systems, but for more complex systems which need SQL, don't use an ORM. Mixing ORMs with raw SQL generally mixes and breaks layers of abstraction. This leads to a situation where the overall system is more complex than having a sane relational abstraction. For example, ORMs do a lot implicitly. A code change at the language level, with something like the Django ORM, can and will break your SQL code. Your data logic is also split across two places.

The only time I've seen this work is for SQL for one-off analytics done at a command line, where the SQL code is never intended to be reused.

EITHER:

- Use an ORM, if you are building something simple like a todo list or a basic eCommerce web site; or

- Use full SQL if you are doing something more complex (e.g. if you ever expect to do analytics); or

- If your programmers don't understand SQL, consider whether you want an ORM, a nosql, or to find programmers better matched to the problem domain.

(Footnote: Many good programmers don't understand SQL; that's okay. They just shouldn't be designing databases, any more than e.g. database experts should be designing machine learning algorithms, or machine learning experts should be designing front-end user interfaces. They're different skill domains, and they're all equally important. The key thing is people should know their skills. Otherwise, you'll get an unusable UX, a regression as our ML model, and a broken schema. This is especially true for something which looks simple on the surface but has deep theory behind it. ORMs make it look easy.)

[jasfi]

Then you'd never use an ORM, because you might require something an ORM can't handle at some point. I don't see why a coder couldn't handle a mix of both. The other factor is that ORMs tend to add features over time. Something that would require raw SQL today might be more elegantly handled with an ORM's language two years from now.

[blagie]

You missed the point entirely.

Language like "require raw SQL today might be more elegantly handled with an ORM's language" suggests that you do not understand the elegance of SQL or the relational data model.

However, you are correct. I used ORMs less and less often as I became a better SWE. They can save time on toy projects, but for those, I usually use a NoSQL or KVS directly.

[jasfi]

I understand SQL and the relational model very well. But once I start using an ORM I want to keep using it for consistency, unless it's not the right tool for the job. Complex queries are usually the reason. Even if the ORM can technically do it, sometimes SQL is just more elegant, faster to write and I can be sure of doing it right.

[kaba0]

If you don’t know SQL, you shouldn’t touch ORM either, no one ever said that you can.

Also, it’s pretty reductionist to say that it is only good for simple systems, when in fact, huge services are running it at almost all companies.