Hacker News Reader

Comment by olavk | Hacker News Reader

Writing SQL by hand does not solve typical performance problems like n+1 queries. If on the other hand you know enough to avoid n+1 queries, then you can also avoid them when using an ORM, and save a lot of work.

If you like writing SQL by hand, by all means do so, but you will not automatically get better performance by handwritten SQL as compared to ORM generated SQL.

View on HN

Sorry, I believe I wasn't clear.

Definitely writing plain SQL does not solve performance issues. However, it does force the developer to draw a clear line distinguishing where he is accessing the database and where he is working with in memory data structures.

No, it's not automatically more performant; it's more that you can optimise hand-written SQL for your specific schema and use case. You can't do that with ORM-written SQL.

Depends on what kind of optimizations, and on the ORM I guess. The major problems described in the article, like n+1 queries and filtering on the client rather than in the database seem to be easier to fix in an ORM than in hand-written SQL with boilerplate wrappers. (Of course they are also easier to introduce in an ORM if you don't know what you are doing, but such is the curse of powerful abstractions.)

Even things like query hints can be easily applied in the ORM's I know. It is kind of hacky since it breaks abstraction layers - but so is query hints in SQL.

But of course there can be some special cases where you just have to drop down to raw SQL for some reason. All ORM's I know allow this.

Depends on the ORM. SQLAchemy will let you write any query via the ORM

Sure, writing SQL won't solve design problems, but some ORMs need multiple queries to deliver data with relationships, joins, etc, that could be done in a single SQL query.

What ORM's does not support joins?

Waterline (for Sails.js) is horrible. Last I looked there's no way to do a kind of `deepPopulate` (requiring an inner join)

Sorry you feel that way! The rest of the team and I work hard on it as often as we can. But deep populate is not a feature we’ll be adding— Sails and Waterline are opinionated, and I don’t feel that the performance penalty and potential issues are worth it— instead, we recommend using a native SQL query when you need to do a custom join.

Built in support for WHERE subqueries, on the other hand, is on our roadmap. Currently working to finish core MSSQL support first though. Hope that helps!

I imagine all of the non-toy ones would support joins for getting raw tabular data or for restricting what single kind of item (e.g. "Customer") you're pulling out.

Where it might get trickier is when you have something like a Customer-Region-Vendor join, and you actually want it to go ahead and create objects for the all of the Customers and Regions and Vendors whose data was pulled out of that one select.

It is actually not that bad if instead of a single query, you do one query per table.

It even offsets some of the burden to the app, which is generally easier to scale than the database.

The idea is that you query the "root" table, loop over the results and build an array of IDs, then do additional queries to the other tables with a "where whatever_id IN (...)".

My understanding is that a lot of SQL drivers support compressing the data anyway, so that the server (and client) avoid duplicating the data over and over just to fill the rectangular result.

In NHibernate and Entity Framework you just say .Include("Region").Include("Vendor") to eagerly load the associated entities. I imagine other ORM's have similar facilities.

SQL is way more expressive than most ORMs, so solving problems is easier in general.

Reply on news.ycombinator.com