3 ms·
I have seen nothing but problems with the whole Active Record/ORM pattern in the last 15 years.. mostly java enterprise software. The problems existed before b
by ben7799 7y ago
I have seen nothing but problems with the whole Active Record/ORM pattern in the last 15 years.. mostly java enterprise software. The problems existed before but IME they've gotten a lot worse. I'm pretty much in total agreement with the author, although he doesn't touch on all the points.
The "pattern" (pun intended) always goes like this:
- Gotta get 1.0 out really fast
- Agile Dev really coming on strong last 15 years
- Architect/early dev lead is not a DB guy
- ORM + Active Record looks attractive and fast due to less code
- Junior devs don't even have to learn SQL
- Simple Active Record architectures let you layer on new stuff to get the all important 2-week sprint demo. Since Agile overvalues the sprint demo & showing stuff in the UI is what matters to PMs performance doesn't matter and gets ignored here. Infrastructure work for future scaling doesn't count as points and/or is considered poor use of time.
- Tons of entities & repositories based around Active record start getting built, it saves tons and tons of code over hand written/optimized SQL code
- Project launches and starts getting customers, getting bigger, needs to scale
- Active Record & Naive ORM generated queries start breaking down due to locking too many rows in DB
- Database deadlocks eventually start happening
- DB Connection pools eventually start running out of connections
- Customers are furious
- New Upper management comes in and wants to rein in PM to try and get developers to work on the massive tech debt. Agile starts to not even work since tech debt makes it look like no work is happening since it doesn't demo.
- Developers start having to piecemeal replace some ORM generated queries with native queries/query builder type patterns
- Eventually the team starts to have to rip the ORM out completely to continue scaling.
The alternate pattern that happens is that the team gets hot under the collar to drop the SQL database for a column-store/NoSql database. The problem wasn't the SQL database here but bad usage of patterns that the NoSQL DB probably doesn't support if it is not an ACID DB.
My feeling is most of these ORM based/Active Record type systems are often 3-4 orders of magnitude slower. Fixing some of this is somewhat one of my specialties.. I have rewritten many stacks that were taking minutes to finish and had them working in < 1 second once the ORM was taken out of the picture.
- dpc_pw 7y agoThis comment is spot on. I've seen similar scenarios myself. :) 99% of articles like the above one come down to: "developers wanted to pretend there isn't some underlying data model underneath, and abstracted it away". The problem isn't that much in ORMs / query builds etc. It's with "Objects" itself, and the idea that one can abstract away the data model and pretend the business code can be written as a bunch of OOP classes and such. It seems like a genius move at the beginning but hits a really steep cliff once the load and complexity of problems incrementally increases. When it starts to happen it's actually funny how not many people can actually realize what happens, and they usually struggle with band-aid solutions and blaming irrelevant pieces. I decided to post on twitter about it: https://twitter.com/dpc_pw/status/1240719977071575040 https://twitter.com/dpc_pw/status/1240719977071575040 in case anyone is interested.