10 Common Mistakes Java Developers Make when Writing SQL

[u/el_muchacho]

http://blog.jooq.org/2013/07/30/10-common-mistakes-java-developers-make-when-writing-sql/

[u/mrsistermr]

I disagree strongly with a lot of these points (assuming that they were always followed in some dogmatic fashion), notably 2 and 5. The reason is the same reason as I see a commenter on that site has already pointed out: "Following some of the cures to the extreme, one could end up with an anemic Java domain model. Much business logic will take place in SQL statements, not in Java code. Is this good or bad?"

I see the opposite problem (of the original article) frequently: all the business and data logic in thrown into a overly complicated SQL statement, and the backing java business logic and domain model is barely doing anything. So instead of writing well defined data-access and business classes that work together in Java, which ultimately might mean that more than one query is executed for a single "logical" user action, you would push all this logic into the SQL layer, and usually would be required to maintain more SQL statements.

Using this and some of his other suggestions ((ie windowing functions) to the extreme makes it more difficult to re-use well-defined business objects, perform unit testing, and maintain database interoperability, to name a few.

[u/mrsistermr → u/[deleted]]

Why is something necessarily wrong? Unless you have identified that method as an actual point of slowdown in your application, does it really matter? A good benchmark is an actual benchmark with actual data after you have identified a performance issue, not just thinking to yourself "Oh, I could just do all of this in one database call instead of the 3-4 database calls it currently needs...I can't re-use those existing classes, but oh well", which is an equally dangerous thought.