Hacker News new | ask | show | jobs
by residentfoam 2461 days ago
I used ORMs JPA/Hibernate in several projects/teams and the outcome is always the same: things always get messy and overcomplicated, few reasons :

- they push developers to design super-normalized db schemas that look beautiful on paper but are horrible in practice

- the average developer has a very superficial knowledge of how ORMs work and this often leads to bad code/performance

- soon or later you will find yourself fighting the "framework" because what you are trying to do does not fit their model (e.g: upsert)

In my experience, this whole idea of abstracting from the DB is faulty at its root. You want your code to be close to the DB so that you can use all the greatest and latest functionalities without waiting for the framework X to support it.

I have found that JOOQ or simply Spring JdbcTemplate in most cases are more than enough.

2 comments

Agreed! I've found JOOQ to be excellent.

Generally ORMs try to abstract away the database entirely. This is mostly fine for CRUD stuff where you really just want to persistently stash away something basic off host. If you could write perfect uncrashing programs you'd probably just keep them in memory.

As soon as you need to find things, especially based on their relationships, you'll need to be aware of what indexes you have available at least. Eventually you'll want to have control of the precise query

JOOQ lets you compose queries programmatically without really hindering you from producing any query you want but not forcing you to glue strings together either.

First your tree needs an apple, then it needs a pear, and then a fig, and after a year or two of grafting other things on you end up wishing you'd just created a cornucopia with a bunch of columns instead of joining a endless fruit because two thirds of the time you need a mix of the fruit anyway.

I'm definitely guilty of over-normalizing at least some of the time, but I'm less convinced that it's related to ORMs so much as it is to frequently having to build things without knowing how related they'll end up being in the future.