3 ms·
All of these endless debates seem to boil down to two different groups who work in two different problem domains talking past each other. I've personally never
by bunderbunder 9y ago
All of these endless debates seem to boil down to two different groups who work in two different problem domains talking past each other.
I've personally never seen an ORM lead to success in the long run. But I also work in a space where queries frequently end up involving something that ORMs typically don't handle well: merge statements and pivot statements, window functions, management of the lock escalation policy to fine-tune performance, temp tables... The list is endless.
What I have not ever worked on is a relatively basic CRUD datastore. Which I realize is what most people are using databases for. So at this point, I'm putting my money on ORMs being a hole in one for that application. Because, otherwise, I just can't reconcile a statement like, "99% of the time, an ORM is fantastic" with the reality I'm living in. In my career, 100% of the time, when an ORM was present, it was invariably the single biggest piece of technical debt.
- manigandham 9y agoYes, you are talking the 1% of use-cases, which is probably more like 10% these days with more complex software. Most business apps are just CRUD, but if you're doing analytics queries and such with tabular/pivot/nested result sets, then an ORM isn't going to do much for you. SQL is the database interface so of course using it directly without abstraction helps you get all the power and control. I have seem some cases though where a query-builder with a solid DSL can be a good middle-ground.
- deleted 9y ago[deleted]