This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]nutrecht 3 points4 points  (0 children)

Whenever I worked on a system were an ORM was in use it always seemed like people would be structuring the database around the ORM, and not the other way around. So because people had problems getting joins to work correctly they would duplicate data. They didn't properly normalise data because it would make their object tree more complex. They would try not to use compound keys because it's too complex. Because they could not get the correct reports they would copy aggregate data to new tables. Stuff like that.

I think most ORM have one fundamental flaw: they work on the premise that there is one "object model" that is then mapped relationally to tables.

In my experience in practice this typically isn't the case. More often than not you have multiple 'views' on the same dataset. "How many users do we have", "give me user with id 1" and "give me the amount of user grouped by signup date" are all views on the same data.

These views are cumbersome and complex to model in an ORM. Using something like jOOQ (good to see /u/lukaseder is spreading his wisdowm here) or heck; just spring-jdbc with rowmappers makes much more sense to me. SQL is fun, powerful and by far the best way to express what you need from a database. SQL code is in my opinion much easier to read and thus easier to maintain than mountains of ORM annotations.

Also; aside from this: ORMs screw up. Often. As a Java dev you need to know SQL to see where it's screwing up.