COBOL and SQL are for different purposes, apples and oranges. One can’t be worse than the other. Programmers who have never seen or written COBOL should stop trotting it out as an example of bad. You’d be surprised how many important systems are written in COBOL, and how well-suited it is for the problem domains it was designed for.

I'm alright with that.

I think the problem is that developers love to abstract everything. And with the database often becoming a god object it's often targeted for abstraction.

The problem is, querying data is a complex problem, complicated enough to require a query language.

So the developer goes off to abstract the database for their needs, a helper table object here, a helper row object there and eventually you start to see an Orm appear.

Developers need to be told to stop this behavior.

The abstraction is the thing you are representing in the database, not the database.

Your models should use plain SQL queries to execute behavior.

If you must, setup some helpers to do very basic crud operations, but as soon as you need to really alter a where or a select, drop to SQL, use the language as intended and watch your code suddenly become modular, readable and maintainable.

Yes, this means you will need to write SQL, yes this means you will write a lot of select and where statements, no this is not code duplication, stop freaking out about non problems.

I swear to god DRY is the source of and solution to all developer problems.

Probably more than 30 minutes, SQL may look easy but using it correctly assumes a fairly good understanding of the relational model.

I agree that programmers too often seem to wave database design and integrity aside and create RDBMS/SQL worst-cases with ORMs and terrible queries, and then blame the tools.