Before databases, applications stored information in flat files such as spreadsheets or text documents. This worked for tiny datasets, but it collapsed the moment two people tried to edit the same file, or when a single record had to be found among millions of rows in milliseconds, or when a crash mid-write left the file half-updated and quietly corrupted.
A database solves this by organising data into structured tables that the system can search, update, and protect concurrently. It guarantees that a payment is never half-recorded and that two users never overwrite each other silently, which is nearly impossible to enforce reliably with loose files scattered across a disk and edited by whatever program happens to open them next.
SQL exists because every team needed a shared, standard way to ask these tables questions. Instead of writing custom file-parsing code for each program, you state what data you want, and the database engine figures out the fastest way to retrieve it. That separation is why SQL has survived fifty years.
Analogy🏏Cricket
🏏 Think of it like cricket: Imagine the end of an IPL innings when the scorer announces the team's final total. Just as the scorer does not read out all one hundred and twenty individual deliveries but instead sums them into a single team score, SUM folds many row values into one number. Just as the commentator reports the highest individual score, the average partnership, and the number of wickets, MAX, AVG, and COUNT each summarise the innings differently. Just as a not-out batsman with no deliveries faced does not lower the team average, aggregates skip NULLs when computing. Just as the announcement is one figure no matter whether the innings had fifty deliveries or two hundred and fifty, an aggregate collapses any number of rows into a single result. This reveals why summaries answer the questions about the whole that individual deliveries cannot.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.