5 ms·

know SQL is kind of hard to describe. I also have business people that know SQL, yet don't use (or request, if they knew there are not) indexes. So we get this

know SQL is kind of hard to describe. I also have business people that know SQL, yet don't use (or request, if they knew there are not) indexes. So we get this amalgamation of monstrous subqueries all hitting the same unoptimized fields, of course, blocking the database. I created a mini-training for the onboarding process, so they could at least look for things without killing all our read replicas. But that’s just one step; some people are just not good at it. Fear... fear is having everyone blocked because one person is killing all the replicas for them to work on.

nemothekid 7y ago
That sounds more like an ops problem than a business one. I’ve worked with a number of a non-technical roles that dabble in SQL, and it’s almost always they are querying a data warehousing solution (e.g Redshift, Pig, BigQuery) that doesn’t support indexes to begin with and most times just have to live with the performance. It’s not their job to optimize the database, and it’s no different from seeing that a dev pushed a new feature that causes bad performance as well
- anbotero 7y ago
  It’s not their job to optimize the database, but it sure is to recognize the basic bottlenecks in their scripts. My training addresses things they have to take into account, and how to approach us when they think they need optimization to what they are doing. It’s just that some of them don’t do it. I made it so it’s part of their onboarding process, so they should know who to contact for these things, yet some of them start literally complaining instead of contacting the team that could help them out.
xiphias2 7y ago
The solution to this problem should be setting up resource quotas. That person should reach its quota limits and ask you to help him optimize the query.
- anbotero 7y ago
  I do something similar nowadays, and I’ve established a process for them to consult to us whenever these issues occur, it’s just that some don’t do it, they don’t care about anything. Of course, I’ve created processes that make it easier for my team to deal with people like that, but it doesn’t take away from them not knowing SQL

nemothekid 7y ago

That sounds more like an ops problem than a business one. I’ve worked with a number of a non-technical roles that dabble in SQL, and it’s almost always they are querying a data warehousing solution (e.g Redshift, Pig, BigQuery) that doesn’t support indexes to begin with and most times just have to live with the performance. It’s not their job to optimize the database, and it’s no different from seeing that a dev pushed a new feature that causes bad performance as well

anbotero 7y ago
It’s not their job to optimize the database, but it sure is to recognize the basic bottlenecks in their scripts. My training addresses things they have to take into account, and how to approach us when they think they need optimization to what they are doing. It’s just that some of them don’t do it. I made it so it’s part of their onboarding process, so they should know who to contact for these things, yet some of them start literally complaining instead of contacting the team that could help them out.

xiphias2 7y ago

The solution to this problem should be setting up resource quotas. That person should reach its quota limits and ask you to help him optimize the query.

anbotero 7y ago
I do something similar nowadays, and I’ve established a process for them to consult to us whenever these issues occur, it’s just that some don’t do it, they don’t care about anything. Of course, I’ve created processes that make it easier for my team to deal with people like that, but it doesn’t take away from them not knowing SQL