Schedule Meeting

a

Why managers should learn and use SQL

by | Jul 30, 2024 | SQL Language

Need Help?  Click Here for Expert Support

SQL is the language of data. You write a query, a single sentence in a language that resembles English, and you obtain the data you need. It’s supported by the majority of databases, and the language is pretty standard. If you have a query that works on Oracle, most probably you can run it on PostgreSQL, MariaDB or Snowflake without any change.

Some managers are aware of this, and know SQL pretty well. But many of them don’t understand the language. With this article, I am to explain to them that they are missing the most useful tool in their job.

The need for data

An obvious fact: managers take decisions. It’s their job. But decisions should be based on data. Sure, intuitions and creativity play a big role, they make each of us unique. But data tells us the information we need.

Identify problems

How is your department doing? Are you reaching your goals? To know these things, you use KPIs. You need to check these values periodically, to find out if you’re on track. If you aren’t, you need to know that, because you need to change something, take some action.

KPIs are data, but probably I don’t have to convince you about their importance. What you might not know, is what to do immediately after you saw that a KPI is not good. My answer is: investigate, check more data. Aggregate, filter, join data. The dashboard that shows you the KPIs might not be flexible enough for this investigation work. Because its developers, or the person who set it up, can’t foresee all the exact problems that you need to encounter, and investigate, in your job. You need something as flexible as a language, that you use to ask questions and get answers.

See also my article on the need of a data warehouse for more information on how data makes it possible to investigate business problems.

Identify solutions

Once you identified a problem, you should find solutions to this problem. Don’t fall into the trap of intuition: verifying problems with data, finding a solution with intuition and creativity alone. Solutions must be designed with the data in mind, and validated against data.

Customers of a certain age band are leaving your products. You know that this is happening, you know why. What is the solution? You might make a change in the products, offer discounts, make ads campaigns… any of this might be good or not, but you should validate these ideas against data before spending resources. How much will they cost? How much time will they take? Were similar solutions tried in the past, and what results did they bring? What results can you expect?

Your data software might not provide a reasonably easy way to find this information. But if you know SQL, you can still obtain it.

Take ordinary decisions

Managers take a lot of ordinary decisions, in order to reach a goal at a cost. Their constant job is to make sure that the goal is reached and the cost can be afforded. Which means, for example, budget and deadlines. Needless to say, even if creativity and intuition are involved, you need to check the numbers.

And once the decision is taken, you need to check if it was a good decision or not. You decided to reorganise products documentation: is this decreasing the number of support tickets? You decided to change the refund policies: is the company earning more money from this change, is customer churn increasing? And so on. You need to monitor the effects of the ordinary decisions you take, not just the KPIs. So that, if a project is not working, you can fix it before it’s too late.

Optimise processes

Even when this is not a part of reaching a goal of correcting a KPI, you might occasionally want to investigate how business processes under your control are performing, eliminate bottlenecks and improve their overall efficiency. This will increase your budget, improve your reputation as a manager and your team’s morale, and will be good for the company in general.

To make it possible, your business processes must be properly monitored. Ideally, all data should be available in the company’s data warehouse or in some data lake. While data in a data warehouse is likely to be visualised through some tools and summarised in dashboards, the information you need to optimise a process might not be there. So you’ll need to connect to your data warehouse and run queries manually. And if it happens too often, you might pass these queries to your data engineers and ask them to setup proper dashboards and graphs for that information.

The tools

Using the right tool for the job is important. Without the right tool, finding the needed information might take a long time. You might also need to involve data engineers to obtain certain information from a certain tool. Let’s discuss which tools you can use to work with data, how SQL compares to other tools, and when you should use it.

Business dashboards

Business dashboards are great. I won’t spend a single word to convince you to ditch a dashboard in favour of SQL. But there’s a but, right? And the but is very obvious, in our daily job: in theory dashboards can tell us everything we need, in practice they don’t. Something is always missing, for one reason or another. Every business is unique, it has unique logics, and the way data from different departments is produced and stored in the original source is unique.  So things like data warehouses and dashboards can’t be universal. A data platform can be universal, but the exact graphs that you’ll see on your screen need to be setup by your company data engineers.

So if you miss a certain information, you can ask data engineering to create a certain graph for it. But this takes time, and data engineers end up being overwhelmed with work. Sometimes it’s not even worth it. Especially if you need to see a piece of information only once, and never again. That’s why most managers use Google Sheets, Microsoft Excel, or something similar.

Spreadsheets (Excel)

Excel and Google Sheets are visual tools that resemble a database. They visualise data in a tabular form, and in the simplest cases they are trivial to use. They also provide more advanced features that make calculations automatic and dynamic, and some of these features are rather complex.

Using a spreadsheet can be helpful sometimes. But it’s mostly about presenting data in an intuitive way. For data analysis, databases are generally better. Here are some reasons why spreadsheets are not sufficient:

  • Data is already present in a database. To use a spreadsheet, you need to somehow load data into it: from a file, from a script, etc.
  • Spreadsheets are more prone to human errors. Corrupting data is as easy as clicking on a wrong cell before typing a number.
  • Spreadsheets can be technically unreliable. In the UK, initially COVID-19 data was written into an Excel document, which caused a severe data loss.
  • For big quantities of data, databases are much faster than spreadsheets.
  • Once you’re proficient in SQL, writing a query is usually much faster than creating a sheet.

SQL

SQL is basically the most advanced, flexible and easy tool to get the data you need.

Is it complete? No. It only returns raw data. You might want fancy histograms, clear cake graphs, and so on. To obtain that, you’ll need another tool, or maybe a data engineer that will make the graphs appear for you. But even in that case, things will be easier if you can provide the SQL query that returns the data you want.

As you know, SQL is a language for data. It has all you need to talk about data, and describe the information you want. Of course, you will need to know your table names, and their column names. But that’s only the vocabulary. The language construct and the grammar are universal, and pretty simple. SQL starts to look less simple when you try to do complex things, but even in that case, SQL is the simplest tool you can use to ask your database a question.

Conclusions

Hopefully, this article convinced you of the necessity of learning and using SQL to increase your productivity, and your team productivity. Simply because it will give you the information you need, when you need it, even when you don’t have that information in a dashboard, in the fastest and simplest way.

There are plenty of free resources out there that you can use to teach yourself SQL. There are also plenty of books and paid courses. We offer SQL courses for data analysts that are perfect for managers, as well. Our courses are both remote and in-person, and can be done at your offices. See you in class!

Federico Razzoli

 

All content in this blog is distributed under the CreativeCommons Attribution-ShareAlike 4.0 International license. You can use it for your needs and even modify it, but please refer to Vettabase and the author of the original post. Read more about the terms and conditions: https://creativecommons.org/licenses/by-sa/4.0/

About Federico Razzoli
Federico Razzoli is a database professional, with a preference for open source databases, who has been working with DBMSs since year 2000. In the past 20+ years, he served in a number of companies as a DBA, Database Engineer, Database Consultant and Software Developer. In 2016, Federico summarized his extensive experience with MariaDB in the “Mastering MariaDB” book published by Packt. Being an experienced database events speaker, Federico speaks at professional conferences and meetups and conducts database trainings. He is also a supporter and advocate of open source software. As the Director of Vettabase, Federico does business worldwide but prefers to do it from Scotland where he lives.

Recent Posts

Making the case for stored procedures

Making the case for stored procedures

MariaDB stored procedures and why they should be improved was the title of my talk at MariaDB Server Fest 2023 in Helsinki. My point was that an improved stored procedures implementation would bring benefits to individual users, the MariaDB community, and the two...

How slow is SELECT * ?

How slow is SELECT * ?

The most widely known query optimisation rule is that developers should always avoid SELECT *. Even when all columns are needed, they should list their names, because more columns could be created in the future. But developers find this really annoying: listing the...

Services

Need Help?  Click Here for Expert Support

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *