@Crell And I thought I'm the only one. Running anything that is a little more complex than SELECT * FROM TABLE and maybe some joins is such a pain. SQL is so powerful, versatile and fast, but I feel that most of this is inaccessible due to ORMs that sit between you and the data.
Have you ever worked with JOOQ? It seems to get a lot right in that regard.
@Crell 10 years ago, I felt the same, until I realised that I just lacked XP on these very powerful technologies. Sadly, most projects are devastated by developers that don't use them correctly, because they just "hate" it, so just don't learn it.
What I hate today: thousands of lines of SQL code, some dynamically built with string fragments (even to an embryon of a badly designed ORM..) that is so difficult to maintain as it mostly fails at runtime #java#hibernate#jpa
@motofix I fully agree that building queries via string concat is the wrong approach.
But SQL is a robust, powerful, nuanced language, and adding 10,000 lines of code on top of them that ultimately is running 90% "read from one table into a record object, with 1:1 matching" but makes just writing a bloody SQL query 10x harder is also the wrong approach.
And if you're writing your own almost-SQL DDL on top of it to parse and translate, then you've just lost and should give up. (JPA or Doctrine)
@Crell there is so much more than 1:1 mapping (that saves you tons of SQL writing and maintenance)
There is cache level 1 and 2, there is entity graphs, complex but powerful Criteria API allowing you to combine predicates specifications, automatic batching...
It really worth giving it a try, but with at least one member of the team that does master the subject as much as you seem to master SQL
@motofix I've yet to be on a project (PHP or Kotlin) that has someone who is an actual master in the ORM... Which suggests that they're just too hard to master in the first place.
Add comment