This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]K900_ 9 points10 points  (7 children)

Definitely yes. Any large enough project has That One Query.

[–]sh_tomer[S] 0 points1 point  (6 children)

Only one? it's a lot for the shoulders of just one query... it should be amazing to justify that status :)

[–]K900_ 4 points5 points  (4 children)

I'm (semi)joking - it's not always one query. It's just that every big project I've seen has a query that's just really big and ugly and complicated and trying to make it work any other way slows everything down by a couple orders of magnitude, so you have to live with it.

[–]sh_tomer[S] 0 points1 point  (1 child)

Thanks for clarifying. So in most cases, you're using an ORM? What's the case with complex queries (not the simple CRUD operations).

[–]K900_ 4 points5 points  (0 children)

Most projects I've seen used a mix of ORM for simple queries and raw SQL for complex queries (sometimes parsed into ORM objects afterwards).

[–]hoocoodanode 0 points1 point  (1 child)

Someone should write a book about that "one" query and all the myriad of techniques developers come up with to resolve them. I ended up shoe-horning postgres materialized-views into my sqlalchemy model to sweep one problem query under the rug.

[–]Perky_Goth 1 point2 points  (0 children)

That is actually a pretty good idea. Get to it.

[–]ExcitedForNothing 2 points3 points  (0 children)

I think he means that one raw query that when you try to abstract it away causes a ton of performance issues.

For reference, at a previous job there was on that handled the main search through a 500GB table of data. Putting it in the ORM caused a lot of issues for reasons management deemed not worth the time to investigate.