N+1 in Ruby on Rails

N+1 in Ruby on Rails
visuality.pl

Rails can optionally use SQL migrations, UUIDs for pks, enforce referential integrity with additional options, and create additional indexes easily. The value of ORMs comes in separating domain data modeling from the peculiarities of a DBMS'es SQL flavor.

An ORM should be used to automate the commonplace rather than as a substitute for understanding how to manage and operate a DBMS.

SQL knowledge is often needed for cleanup and ETL work outside of the monolith. There is no substitute for understanding how things deeper in the stack operate.

I remember my engineering manager was freaking out over me using strings instead of symbols because they’re less performant, meanwhile he didn’t know to add indexes to fks lmao.

He clearly cares about performance! Just never came to understand relational databases, which was my day 1 obsession. And doesn’t know how to profile the entire thing to make sure he’s stressing over the things with the largest effect size.

Anyway he got fired and works as a systems guy now. Happy for him lol.

ORMs also usually allow you to drop down to SQL when you have to. They are there to help you, and they expect you to know what you're doing. Like other tools that make so much easy, they do make it easy to shoot yourself in the foot. I won't argue that the average ORM-user is more likely to create shitty-performing code than the average SQL-only-user. However, this speaks to the average population of the tools, not to the tools themselves.

When building a backend, I mostly work with Python and Django, and when interviewing candidates I place heavy value on them knowing what select_related and prefetch_related are. These are ways to void N+1 (akin to includes, I gather).

You can also write shitty queries, subqueries and just terrible stuff overall in SQL. And create shitty data models. Just the other day I had to comb through a PHP codebase that used raw SQL. Do you want to know what it had? N+1 problems.

If you use the ORM with the knowledge that you, as a competent developer, should have, then you most often will get a lot of bang for your buck. You will easily avoid the N+1 problem (and others), while benefitting immensely from what the ORM gives you, such as migrations, (somewhat of a) database independence, easy index creation and manipulation, much faster development times and iteration, an (arguably) much better syntax for creating and documenting the data model, and others.

I will never understand why so many people constantly criticise ORMs while turning a blind-eye to the fact that _most_ of their criticisms are actually criticisms of junior/amateur developers doing junior/amateur developer things. (I don't think you are one of these people)

The right tool for the right job. Sticking just to the ORM and using it blindly is a terrible idea. And I'm sure that extremely large codebases can be made all out of SQL — I'm not bashing it. I'm merely actively defending ORMs (and other tools) because they have their use and they do have very clear advantages — if used correctly.

The actual problem here lies in the Active Record (anti) Pattern. It becomes impossible to distinguish in-memory access from db access. I’m not surprised to find this being particularly prevalent in dynamically typed scripting languages…