Why does SQL exist?

The need appears before the language

A store receives orders on its site, in the store and by telephone. Customer service keeps a customer file, accounting tracks payments and stock has its own sheet. Each tool meets a reasonable local need.

The difficulty begins when the same facts exist in several places. Are Amel Ben Salah and A. Ben Salah the same person? Does P-42 product stay 8 or 11 times? Why does a payment not correspond to any order? As long as no source controls these relationships, two reports can be technically clean and tell two different truths.

When does a base become relevant?

A spreadsheet is excellent for quickly exploring a small dataset, establishing a simulation or preparing a one-off analysis. A database becomes useful when several processes read and modify related data, when rules must be identical for everyone and when history or access rights matter.

The threshold is not a magic number of lines. Ten thousand stable lines managed by one person can remain simple; five hundred orders modified simultaneously by a site, a store and customer service can already request a base.

• Data shared by several actors
• Relations between customers, orders, products and payments
• Rules to be imposed in the same place
• Concurrent changes
• Repeatable responses and histories

Base, DBMS, server and SQL are not the same thing

The database is the organized set of facts and rules. The DBMS is the software that stores them, controls them and executes the operations. PostgreSQL, MySQL and SQL Server are DBMS. A server is the environment that often makes this service accessible to applications and users.

SQL is the language with which we describe a structure, read data, modify it, set constraints or manage certain access. The DBMS share a SQL base, then add their types, functions and tools: we talk about dialects.

The relationship and the rule create trust

A customers table identifies each person by id_client. A command saves this identifier instead of copying the name. A foreign key can then refuse an order linked to a non-existent customer.

The base can also charge a price, prevent a duplicate email or limit a status. These rules do not automatically make all data accurate: they mainly prevent states known to be impossible and make exceptions visible.

CREATE TABLE clients (
  id_client INTEGER PRIMARY KEY,
  email TEXT UNIQUE NOT NULL
);

CREATE TABLE commandes (
  id_commande INTEGER PRIMARY KEY,
  id_client INTEGER NOT NULL REFERENCES clients(id_client),
  montant NUMERIC CHECK (montant >= 0)
);

SQL turns a question into a reproducible result

Once the orders are structured, the question “in which city do we achieve the most revenue?” » has an explicit source, calculation and order. Another person can reread the query, run it on the same scope and check the result.

The query groups the orders by city, adds their amount then sorts the totals from largest to smallest. It is not just a calculation: it documents the method used.

SELECT ville, SUM(montant) AS chiffre_affaires
FROM commandes
GROUP BY ville
ORDER BY chiffre_affaires DESC;

Three misleading ideas to avoid

Understanding the tool’s boundary avoids replacing one naive promise with another.

• “A base eliminates all errors”: it imposes the rules that the team has defined and correctly modeled.
• “SQL is only for analysts”: applications, APIs, business systems and administration teams also use it.
• “We must abandon Excel”: spreadsheets and databases often complement each other; the important thing is to know where the controlled source is located.

Question to ask yourself before choosing a tool

Take a dataset from your work or studies. Who modifies it? What information is repeated? What relationships must always exist? What mistake would be costly? The response better indicates the need for a database than the number of records returned alone.

The free micro-training now lets you spot these inconsistencies, build the relationships and execute the revenue query without asking for an account before success.