Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Imho, ORMs make the easy queries easier (terser) but simply do not cut it for complex queries. So you need some solution for that too.

You could drop down to SQL-as-string-queries, but then you loose all type safety on the queries. We use jOOQ (sort of LINQ on the JVM) which brings significant type safety to the database interaction layer.

Would I use an ORM if I had to start over? No.

Would I use a db + jOOQ if I had to start over? In many cases, yes.

To me they are not so much a anti pattern, but usually come with many anti-patterns, like coupling validation to entities to caching to ...



jOOQ was one of the first times in my career where I (a junior, at the time) went to bat and convinced my company to shell out for a commercially licensed library. Our application was basically nothing but complex queries; getting our ORM, Hibernate 3 back then, to do anything sane & performantly was a nightmare.

Those licenses were money well spent for developer productivity alone, but honestly they've probably paid for themselves multiple times over just in terms of "energy usage at runtime" cost.

It's not always ORMs, but it's a pattern I see over-and-over again, somebody that doesn't know SQL tries to abstract away all the uncomfortable (to them) parts of SQL. It always ends up as an unmaintainable and non-performant disaster. _It's relations all the way down._ If you're going to fight SQL at every turn, you're better off using something other than SQL to store your data. (I still die a little inside every time I open up a SPROC that's just a giant cursor. Won't somebody _please_ think of the sets?)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: