As the old saying goes, ‘if all you have is a hammer, everything looks like a nail’. This is true of the modern work environment. We have never had so much choice of tools to solve problems, yet many people continue to use the same hammer for every problem.
Structured Query Language (SQL) is one of the easiest ways into the world of ‘coded’ data analytics. It’s a powerful tool that lets you access data sets of a billion parameters, and filter it down into something you can actually manage and do something with. It’s an incredibly easy tool to master. As a complete beginner, you could sit down to learn it this afternoon, and use it tomorrow morning in your work. It is also the core skill behind data engineering, a skill that pays well over the average salary these days.
Just as downloading data to an Excel file belongs to another era, SQL is also starting to show its age. Using SQL to build a modern, real-time AI agent is just as bad as copying and pasting data over from one file to another. You’re trying to force an analogue mind on hyper-modern digital jobs.
So, how exactly do we put that afternoon learning SQL to very good use? We’ve pulled together some use cases where the problem needs a SQL solution. We’ll also tell you when to put those SELECT * commands away, and when to let them shine.
When SQL beats the rest
Scenario 1 - You work in accounting and finance, managing ledgers and double-entry bookkeeping
You need to manage bank accounts, process e-commerce transactions, or audit ledgers. Your guiding principle is ACID compliance (Automicity, or ‘All or nothing’, Consistency, Isolation and Durability). In other words, if a user transfers £50, SQL can ensure that £50 is simultaneously subtracted from Account A and added to Account B. If the server crashes mid-transfer, ACID principles ensure that the whole thing rolls back. The money that leaves Account A doesn’t just float around nowhere. It stays in Account A, and someone has to try again.
Transferable takeaway: This is one of the great strengths of SQL. If a single missing or duplicated row means losing real money, or another thing of real value, you use SQL. It will enforce standards on the data.
Scenario 2 - You are managing a highly connected, relational database (for example, a Human Resources System, or the Enterprise Resource Planning System).
You need to track employees, the departments they work for, their payroll history, their managers and performance data and their office locations. It is a complex system. Your biggest win comes from maintaining relational integrity. In other words, you can strictly control all the foreign keys that your system relies on. Nobody can accidentally assign an employee to a department that doesn’t exist. Nobody can accidentally delete a department while there are employees assigned to it.
Transferable takeaway: Look at the complexity of the rules that you have created. When your data integrity depends on an increasingly complex set of rules, SQL can impose order and restrictions and act as a gatekeeper against breaches.
Scenario 3 - You are managing a data warehouse with centralised aggregations
Your job is not easy. You need to calculate the total lifetime value of millions of customers across five years of historical data. Most local programming languages would crash your computer’s memory before you even got started. Using SQL database environments like Snowflake, or BigQuery, you can process that volume of data in SQL databases in the cloud.
Transferable takeaway: When data gets bigger, the rules change. If you need to get one number out of billions of data points, SQL is a good tool to handle the job.
When to step away from SQL
Scenario 1 - You build executive dashboards to support decision making
A regional sales manager has just emailed you to request a click around map to see which stores are hitting their goals this week. She wants to introduce it to her team and use it on a regular basis. Writing a SQL SELECT statement every time a manager wants to filter the data but a different postcode, or by a different date range or product category is highly inefficient. It also slows down decision making. It’s time to turn to software tools, like Power BI or Tableau. Your non-technical colleagues can use the drag and drop interface to get the answers they are looking for after a brief product introduction.
Transferable takeaway: Sometimes it’s just easier to let the Business Intelligence tool write the underlying SQL for you.
Scenario 2 - Your job is to store the chaos!
Say you process 10,000 temperature readings per second from factory sensors. Forcing a database to check relational rules 10,000 times a second is going to create a massive bottleneck. Or, say your job is to scrape thousands of retail websites to track prices. Every website has a different way of structuring its data. Some have images, some have multiple attributes, some change every week! Having the change the rules for each new item that comes in will, over time, break any existing applications you have set up.
Transferable takeaway: SQL requires a strict schema or table design. If you want to add a new column for one example, you have to add for everything. A NoSQL (Not only Structured Query Language) tool like MongoDB will handle that better. It prioritises spectacularly fast write-speeds over strict relational structure.
Scenario 3 - The CEO has just noticed a 15% drop in revenue this week and asks ‘Why is our revenue dropping? What is causing it and how do we fix it?’
This is a slightly trick scenario. You could use SQL to fetch the information that you believe you need to answer this question. You could get the data from the warehouse on what product lines dropped. You could query the marketing database to see if ad traffic fell. You could query your CRM data to check if sales reps are losing deals. You might even have customer support logs that reveal a technical issue. This would be helpful to compile a report to share with your colleagues. You can review it and try to understand why things have changed. But this will take a good couple of days, dozens of queries and a fair bit of human interpretation.
If you used an AI Data Agent, it won’t just execute a single query. Agents have the ability to reason and plan. If you give it an open ended question ‘Why have our sales figures dropped?’ it will go away and execute a number of tasks. It will write the SQL queries to isolate relevant data in the warehouse and identify which products dropped. It will call an API to check if the issue is server error logs. It can cross reference your CRM to see if specific contracts stalled and read customer support emails. It can suggest an explanation very quickly - Revenue dropped because a bug in Tuesday’s software update broke the checkout page for our European users. There was a 40% spike in abandoned carts and 200 support tickets. Of course, there is scope for error in the response - we are working with probabilities, not certainty.
Transferable takeaways: When you have an open ended business question and you need a quick answer, an agent can usually deliver responses much faster. If you have a specific query and the stakes are high, SQL is your solution.
So, the more tools we have, the more options we have to fix the problems in front of us, and the ability to fix problems keeps us highly in demand. If you would like to learn more about SQL, how to build your own agents with no coding, or any of the more advanced tools in this article, please visit ioaglobal.org . We are here to support you in the digital workspace.
