Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

ORM: You ask for something and you don't care _how_ its fetched.

Query Builder: You build a query, just not in SQL. So you can get around SQL's limitations (like composition)



> ORM: You ask for something and you don't care _how_ its fetched.

Try this:

> ORM: You ask for something and because you've researched and found a well-written, quality ORM you trust that it will create a sane query.

or possibly:

> ORM: You ask for something and you accept the tradeoffs vs hand-written queries but you're content that it's the correct tradeoff for your use-case.

There's plenty of places for bottlenecks to hide and premature optimization is the root of at least some evils.


> ORM: You ask for something and because you've researched and found a well-written, quality ORM you trust that it will create a sane query.

Ha. More like:

ORM: You've just joined a project already using an ORM selected by an 'architect' that no longer works here. Everything is fine until you start testing your system with a database sufficiently populated with real-world data. You and the DBA spend the next next 6 months trying to get the damn ORM to generate performant SQL (you even call Oracle support, which promptly dispatches an "engineer" who tries to sell you on another $500k of crap you don't need that won't really address the problem). You eventually just start writing queries by hand wherever you find a bottleneck caused by the naive ORM, which you could have done at the outset, but no one who actually knew SQL well enough was on the team back then.


IME, it should never take more than a few hours to run down why the ORM made such a query. At a minimum most RDBMS's have query logging and can explain queries.

Ironically the last time I had a big ORM performance problem was Hibernate eager loading all joins. Diagnosing and fixing it didn't take more than an hour. (Though we did have a very experienced DBA at the time.) YMMV


You have to known when to break free of the ORM. They are great for graphs of CRUD operations and pretty nasty for much of anything else. You may come to a different conclusion depending on the project and dataset of course.


And when you break free of the ORM prey to god that your ORM doesn't have a hidden cache somewhere. If it does then you spent a week tear out your hair until you figger out that the ORM' cache caused all the trouble.


This sounds like a distinction that you personally have made, that the wider community probably won't agree on.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: