‪Admittedly as an engineer my SQL knowledge is minimal and I develop database driven web applications on a daily basis. Most programming languages have object-relational-mappers that handle things for me. I have a unified object store with easy querying and SQL is handled form me.‬ You don’t have to be an expert in every technology to be an engineer.

Until it breaks in a critical project.

Until the ORM layer goes nuts, in unexpected and fun ways that... wait for it..... breaks production.

GL!

I heavily advise against this. I will grant you that you don't need to ve well versed in all the topics of web development. But proper SQL utilization is absolutely important to know and to know well.

@AleCx04 I agree. SQL can become the source of a performance issue. Therefore you should know what you are doing to be able to fix it.

Basically what everyone else said. It bears some explanation as to the real world consequences of not knowing your persistence mechanism.

Coding to an abstraction tends to lead to issues without a general understanding of the principles governing that abstraction. Using ORMs is fine, only knowing their mechanisms makes you reliant on the tool rather than a technology.

Is the resulting query N+1? Is this query able to execute in parallel? Are my expressions eager or lazy? You don't know without being able to interpret the query translation, and as such you can't ask the right questions. When everything is relative to the abstraction, troubleshooting performance and behavior issues become arcane.

It's probably more accurate to say you don't need to know SQL, yet. Everything is fine now, but at extents and maturity when you encounter significant performance problems or errors that shouldn't exist given the constraints of the ORM, you'll have to learn SQL to handle those issues.

The question then becomes, do I invest in learning SQL now, when everything is great, or do I wait for the moment a DBA/support personnel sends you a trace and says, "your system is sending us this query and its performance is causing significant issues, fix it." They won't know your ORM, but they will know SQL and won't hesitate to bus your credibility when they're under fire.

To put it another way, if your kitchen is on fire, you could learn to use a fire extinguisher, or you can wait on the fireman abstraction to handle the issue.

I remember from my old job at a goverment branch, we were looking why certain application was slow. It was done by contractor and they used openJPA (i think, it was some Java thing) as ORM. We looked at actual queries at db level and it was the first time that i saw a sql that filled my whole monitor.

The framework was generating huge queries with redundant stuff in it. After they replaced certain queries with raw sql, it started working better.

And that's why i don't trust abstractions over sql very much :) Or maybe "trust, but verify".

I have trust issues when it comes to code.

Too many times have I walked into a burning pit of hell only to realise the dev that lit the fire could have learnt something to prevent the rise of Satan and the demonic powers of shit throwing the business have acquired over the years.

- sorry I've been playing doom to much recently😅

SQL is more then just selecting a few fields and iterating over them, sure you can write 20 select queries or you can write one that collects all the data you need and collects it's faster, DBS's need as much time and care (if not more) as the rest of your system as they will at some point without fail, become the bottleneck.

The whole nothings changed so it ain't broken attitude a lot of devs get doesn't work with databases, they change every day, more and more data is added, more and more indexes are created, and at some point that query that's ran under a second for 3 years suddenly takes 60 seconds to execute, knowing how to react can mean the difference of 1-2 hours of shit server load vs days.

But it's alright, we devil spawn slayers are around somewhere to wipe the shit under the rug and put out yet another avoidable fire.

I'm not saying be an expert on the matter, just be prepared for the end of the world.

You could half-ass any part of your process, and you choose to half-ass the single one that bears the weight of all data handled by your application.