Hacker News Reader

Comment by n_e | Hacker News Reader

Although the problem will be a lot less severe than with remote servers, this is still sub-optimal:

- the data passed from one query to the next still needs to move from the database process to the service process and back

- the queries will always be executed in the order they are in the code, denying the optimizer the opportunity to execute the full query in the best order

View on HN

With SQLite there is no "database process" unless you are explicitly only using a dedicated process to make the queries through which isn't necessary with SQLite anyway.

That being said, the problem here is not whether N+1 is a problem or not, but rather if, given the immense amount of unnecessary complexity that using an ORM brings, it is appropriate to use an ORM.

There is still also non-zero overhead associated with making queries in general, in both the querying and query-answering process.

The ceiling of the range where you can get away with this without user-visible performance impact will be much higher, and the relative performance difference may be smaller, but in general fewer queries for the same data will still be better in general.

Even with an in-process DB, you're still essentially making a sort of context switch.

Piling on about overhead (and SQLite), many high-level languages take some hit for using an FFI. So you're still incentivized to avoid tons of SQLite calls.

https://github.com/dyu/ffi-overhead

Sub optimal in one regard, but if segmenting queries makes for simpler, easier to read and easier to debug code, then you're optimising dev time. Often this is the right tradeoff to make.

Reply on news.ycombinator.com