[bakugo]

This again...

No, just because raw SQL queries work great for your toy blog/todo app with 3 tables and simple relationships, doesn't mean they work great for real world business applications with 100 tables and complex networks of relationships. Try maintaining the latter before you make blanket claims like "ORM bad".

[manuelabeledo]

> just because raw SQL queries work great for your toy blog/todo app with 3 tables

In my experience, ORMs work well for toy projects, but become cumbersome to maintain in enterprise ones, especially where performance matters. There is a large overlap between engineers who refuse to learn SQL because it's not "convenient", and those who prefer ORMs because they are "easier", resulting in cohorts that don't know how to use either.

But also, I don't see how ORMs make managing large databases any easier, other than those with embedded migration capabilities, which can be very well extracted to their own tools.

[nubinetwork]

I guess I'll bite. How/When do you know you actually need an ORM?

[bakugo]

If you're asking yourself "do I need an ORM?", then you should probably default to using one, unless you understand your complete use case well enough to know you'd be better off without one.

It's also important to note that not all ORMs are created equal. Some are more restrictive than others, and that should also be taken into account.

[rrr_oh_man]

Maybe if you add a new variable to a table and need it in a query five views down? But honestly I much prefer using assisted queries like the supabase package, but leaving the tables alone. ORM can be very unwieldy in an unstable environment.

I’ve once tried a "type-safe" SQL extension and it was pretty neat.

Imho something like this is much more useful than a lot of ORM-overhead.