[pphysch]

Raw SQL is great for simple queries, but gets old quick when you are dealing with "higher order" parameterized queries with lots of joins / optional clauses and you may end up creating an awful bespoke query builder to address these challenges. Or just piles of big similar queries that make it impossible to refactor your data model.

The sweet spot is an ORM that embraces dropping down into raw SQL where needed, instead of forcing bad half-complete DSL everywhere.

[Twisell]

Sorry for the burn, but you managed to contradict yourself mid writting (or maybe you used an AI that messed up your point?)

>Raw SQL is great for simple queries, but gets old quick when you are dealing with "higher order" parameterized queries (...)

>The sweet spot is an ORM that embraces dropping down into raw SQL where needed {...)

So basically you said that ORM are great only for the sweet spot of "mildy complex query". Because Raw SQL is great for simple query, and can be invoked when the ORM is not enough for highly complex query.

So I'd stick with my strategy of mastering raw SQL. I never felt the need of switching tool specifically for mildy difficult query. These are usually boring repetitive stuff than you can usually abstract away with a stored procedure (or in a external parametrized SQL script if your development guideline is to avoid storing any business logic in the database)

PS : But of course ORM is still very relevant if your application aim to be compatible with different database vendors and you are ok to never optimize query yourself directly beyond what your ORM vendor can provide.

[kovacs_]

I think the point they were trying to make is for using ORM for everything until you need a query complex enough or performant enough to drop back to a raw SQL layer.

That's the pattern I've seen the most with ORM setups these days. That or dropping performance heavy sql into stored procedures but in the end it's all a matrix of ease of use/maintainability in some scenarios vs full control and performance tuning and what makes sense for that use case.

[Twisell]

Then please forgive I was triggered on their introductory expression "Raw SQL is great for simple queries, (...)"

I understand your point but I'm not sure it's efficiency to use an ORM that abstract the easy stuff away from the programmer but rely on expert level knowledge to solve what remain. Because at this point the developer that build everything with an ORM will either: - Face complexs SQL query that he'll have to build from the ground up by summoning expert SQL skills they probably haven't use for a while - Seek external help from an SQL expert than doesn't know how the system was build in the first place*

If you know you'll need database specific SQL optimizations on complex query in the end, I guess using SQL everywhere could also make sense. Same language and code logic from simple to complex query and a complexity gradient in between.

*I guess same point could be made about vibe coding actually.

[victorbjorklund]

Not OP but as I understand it they say RAW sql works great for the very basic stuff. But when it becomes a bit more complicated it is easier to mess up and an ORM is preferred. Then you have the very complex queries where ORM just become more difficult or creates bad performance. Then you have to use raw sql.

So basically raw sql or orm does not matter for very simple queries. For more standard queries with lots of joins and where clauses ORM is better to not deal with complex sql. Then you reach a point where you must use raw sql because the alternative is worse.

In most apps most queries is probably in that middle chunk.

[Izkata]

> Then please forgive I was triggered on their introductory expression "Raw SQL is great for simple queries, (...)"

I think they might have had a second point in there that they removed but accidentally left part in. This part of the first sentence:

> Raw SQL is great for simple queries, but gets old quick

Sounds like it belongs on a point about boilerplate around sending queries and reading results, that ORMs do for you.

[pphysch]

Not a good look to accuse others of AI spam because you can't immediately grasp their point. Others clarified it well.

ORM has substantial utility beyond just abstracting across different backends (I personally think that is one of the worst reasons to use an ORM, migrating or joining across entire production database systems is not something you ever take lightly).

> So I'd stick with my strategy of mastering raw SQL. I never felt the need of switching tool specifically for mildy difficult query.

FWIW this attitude reminds me of devs who insist Haskell or Emacs whatever is the one true technology that can do everything. Hard to work with. They build ivory towers, complicated systems that only the author can enter.

SQL is great but has its limits. Same for ORMs. Sweet spot is in the gray zone.