Same here but no one hires for a DBA, just keep moving me between projects to put out fires or get them finished one-time or not later then they're already running. Few are actually interested in learning details of designing schema/indexes/queries to be good before there's a problem. I keep telling them to put example SQL queries in PR descriptions with EXPLAIN query plans hoping it will click for them.
My view is that the schema + queries is the essential performance consideration. The code that goes from one persisted state to another is largely plumbing implementation detail. Of course there also lots of precise logic there but it's a healthy alternate view. The first thing I do on any project I join is make a big ERD to know the names, cardinalities, and relations (and wonder how they keep changing that without an up-to-date picture).
I think this is one of those things that’s situation dependent. It sounds to me like your organization has a lot of data that needs to be processed. In that case it’s extremely important to write your SQL so that it executes efficiently. SQL does a lot under the hood but it won’t automatically switch a left join to an inner join if it figures out that would have no impact on the output. So if you’re in a situation where that’s important, you’ll want your pipeline building employees to be using best practices. I run into a similar problem with my peers (data scientists) when I ask them to provide a SQL query link to their charts / analysis. It’s like pulling teeth but to me it seems obvious that everyone should be doing it as mistakes would be found sooner and others could build off of your work resulting in a positive feedback loop of data understanding. But nope, not everyone seems to care about that.
People are spread too thin with their skills already, so it's no wonder they don't want to learn yet another thing (especially if you aren't the one signing their checks). The databases can be forgiving and EXPLAINs are not easy to interpret correctly for people who don't know databases that well.
A proactive solution of hiring a DBA to build things along with the FE/BE developers will likely never get traction due to costs. Businesses regularly put off performance and optimization until later and they still make good money in spite of that.
So true. What I've been doing is rotating myself through different parts of the organization on projects that need a big schema/performance improvement. And hoping to have imparted some interest and knowledge in maintaining good schema design and performance along the way.
My view is that the schema + queries is the essential performance consideration. The code that goes from one persisted state to another is largely plumbing implementation detail. Of course there also lots of precise logic there but it's a healthy alternate view. The first thing I do on any project I join is make a big ERD to know the names, cardinalities, and relations (and wonder how they keep changing that without an up-to-date picture).