| ▲ | pphysch 3 hours ago | |||||||
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 2 hours ago | parent [-] | |||||||
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. | ||||||||
| ||||||||