Our C# developers (who know just enough SQL to be dangerous) write code using Entity Framework and I have trust that Microsoft will generate good SQL. So far so good - and it's getting better with every version on EF Core. This approach of strongly typed code that will give syntax errors when I change something in the model beats stored procedures every time. Maintenance is king!
Occasionally, I would love to get an advice from a humble DBA who can analyze the generated SQL and work with the developers to help them tune their C# code. Instead, I usually get the feedback from a DBA (who doesn't know any C# and is extremely dangerous) that C# code should just invoke a stored procedure that will be much more efficient.
Virshu, OK, so you knock the developers and you knock the DBA's. And you think an automated tool can write better code. Got it.
Better be careful. Someday you may actgually NEED one of those 'extremely dangerous' DBA's. I was a dba for years, but long before that I was a developer fluent in at least five programming languages that I can remember, so been there done that. In my time we had to learn to be good developers before we got the opportunity to even dream of being DBA's and SQL Developers.
Right, I'm NOT a humble DBA, but was a pretty good one. I would no longer claim to have front-end languaage developer skills, but do still have the understanding and empathy for those who do. In my day I saw some really, reallly bad SQL development and spent lots of time on improvements.
One thing for sure is that long run it's far less expensive to fix and improve bad SQL than it is to buy more haradware and software resources to hide bad code.
My last gig was in a development effort in which we had created and maintained nearly 500 stored procedures, none of which were generated by software, and only a few of which were created by developers. I'd match the SQL skills of our DBA group against any and all other sources.
Instead of criticizing the developers, pitch in and help them be better.
One of the best days of my IT career was the day I told my boss if the problem was so simple he should go fix it himself.