I believe the primary driver here is the overwhelming reliance upon ORMs when building anything with your average web framework—be it Python, Ruby, JavaScript,

I believe the primary driver here is the overwhelming reliance upon ORMs when building anything with your average web framework—be it Python, Ruby, JavaScript, or whatever. Sure, these ORMs may, and usually do, offer ways to write and execute queries directly in SQL, but a vast majority of current developers seems to always reach for the ORM. Now, for simple CRUD apps, sure, that’ll help get you going quickly without having to think outside your chosen language. But this then snowballs into never thinking outside your chosen language. When ORMs are the average developer’s introduction and sole interface to using databases, we wind up with all the StackOverflow questions about how to write query X in ORM Y, when it could have been written as an SQL statement, sproc, or function, and executed directly (and probably more efficiently). It’s both amusing and sad when I see or hear of someone being unable to interact with their db directly. I can only suspect they actually believe the ORM is the way to interact with their db. Oh, they may know SQL exists, but that’s about it. This problematic state of affairs is only compounded by the fact that ORMs don’t properly and easily handle taking constraint, validation, and other data-focused application logic and actually writing it into the schema (some ORMs are better/worse at this than others, of course). They all seem to just default to letting as much of it be application-level code as possible. This then leaves new developers with the impression this is where such code belongs, so they never experience anything telling them it should be anywhere else. It’d be great to see more education offered within ORM docs, but the really important stuff seems to often be there only if you already know what you’re looking for. I’ve seen so many models defined over the years without indexes on the most obvious columns that are queried a bajillion times. Or maybe you can set a unique constraint on certain fields without a bunch of effort—sqlalchemy is decent at this in the Python world—but then you have to have unique validators for forms, rather than relying on the db to complain about a violation of the the constraint, and the ORM catching it in a friendly way devs can bubble up when needed. Oh, and then some insist on adding client-side validation of that same constraint. So, you take a constraint that matters at the db level, and is already easily handled at the db level, and people are writing client and server validation to enforce a condition the db is already supposed to be enforcing. There’s madness here. Maybe it’s just me, though.