3 ms·
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
by n_e 4y ago
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
- jerf 4y agoThere 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.
- eatonphil 4y agoPiling 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 https://github.com/dyu/ffi-overhead
- Arch-TK 4y agoWith 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.
- davnicwil 4y agoSub 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.