3 ms·

It never was. Using ORM made the pool of candidates to work on a codebase bigger, and it made applications better on average (not because of some ultimate perfo

It never was. Using ORM made the pool of candidates to work on a codebase bigger, and it made applications better on average (not because of some ultimate performance or security metric but because it evens out all the horrible hacks). In a vacuum, on a super specialised team or in an academic setting it might be something one could write such an article about, but the average CRUD-app-programmer tends to not have the bandwidth or specialisation to spend effort on manual data wrangling. The same applies the other way as well: as soon as saving object-level details or fetching related data becomes something that requires thinking, plenty of junior and medior engineers end up forcing loads and saves by hand. Not because it's the best way or the only thing they could do, but because it works, it delivers the features and makes the company money, and everyone else also working on the code understands what is happening. In a way, 'bad' code that works and can be worked with is not all that 'bad'...

ttfkam 3y ago
If you're using JS or Python, the SQL call just returns an array of objects/records. No muss. No fuss. If you're using something like Sqlx in Rust, the SQL is not just checked for validity, it seamlessly assigns the result set to the exact type you define for that use case. ORMs make basic CRUD fast and easy while making everything else massively more complex. If all you ever need is CRUD, I guess that's alright. Many of us work with projects that far exceed it though. And for that, you need to know SQL and not just some half-baked SQL punch through the ORM deigns to afford to you.
- swader999 3y ago
  You can use cqrs to just build simple reporting views that orms get and set and for your real concurrency boundaries build aggregates that hydrate their state from all the events that have happened to it. Handles complexity to the nines and gets your reports and screens wicked fast at any scale you can imagine. You won't need to join much or optimize queries. Maybe figure out a few non obvious indexes.
  - ttfkam 3y ago
    > And for that, you need to know SQL and not just some half-baked SQL punch through the ORM deigns to afford to you. That and read replicas. Relying on the ORM will not save you, but knowledge of SQL (specifically materialized views) will.

ttfkam 3y ago

If you're using JS or Python, the SQL call just returns an array of objects/records. No muss. No fuss. If you're using something like Sqlx in Rust, the SQL is not just checked for validity, it seamlessly assigns the result set to the exact type you define for that use case. ORMs make basic CRUD fast and easy while making everything else massively more complex. If all you ever need is CRUD, I guess that's alright. Many of us work with projects that far exceed it though. And for that, you need to know SQL and not just some half-baked SQL punch through the ORM deigns to afford to you.

swader999 3y ago
You can use cqrs to just build simple reporting views that orms get and set and for your real concurrency boundaries build aggregates that hydrate their state from all the events that have happened to it. Handles complexity to the nines and gets your reports and screens wicked fast at any scale you can imagine. You won't need to join much or optimize queries. Maybe figure out a few non obvious indexes.
- ttfkam 3y ago
  > And for that, you need to know SQL and not just some half-baked SQL punch through the ORM deigns to afford to you. That and read replicas. Relying on the ORM will not save you, but knowledge of SQL (specifically materialized views) will.