Excel or database: how to choose?

Excel and a database do not solve exactly the same problem

A spreadsheet combines data, formulas and presentation in a flexible interface. It is quick for a one-off analysis, a simulation, a budget or a small follow-up where one person masters the context.

A relational basis separates structured data from its multiple uses. It becomes interesting when a site, a report, an API and several employees must share the same customers, orders or stocks with common rules.

Five questions more useful than “how many lines?” »

Volume matters, but collaboration and the fact lifecycle often reveal the need sooner.

• How many people or systems write to the source?
• Should customers, products and operations be linked?
• Should a rule be imposed regardless of the application?
• Can two changes happen at the same time?
• Should we limit access, historicize or reproduce a report?

When the spreadsheet is a very good choice

Someone explores a monthly export of 2,000 rows, adds some calculations, checks assumptions, and produces a chart. The source is fixed, the analysis short and the formulas visible to its author: a spreadsheet offers excellent working speed.

It is also suitable for a prototype. Testing a data dictionary and a first structure in a sheet can avoid building a poorly understood database too early.

When the base becomes the best base

A store receives orders all day long. The site reduces stock, the store sells over the counter, customer service changes an address and accounting confirms the payment. Facts are linked, continuously modified and used by multiple processes.

A base helps identify each object, prevents some inconsistencies, and applies a transaction when multiple changes need to succeed together. Reports and spreadsheets can then read this source.

The hybrid model is often the most realistic

The base keeps the facts shared and controlled. A SQL view prepares a stable perimeter. Excel or Power BI connects to this view for analysis and presentation. Each tool remains in its role.

This architecture avoids transforming the spreadsheet into an improvised server while preserving its flexibility for business users.

CREATE VIEW ventes_mensuelles AS
SELECT DATE_TRUNC('month', date_commande) AS mois,
       SUM(montant) AS chiffre_affaires
FROM commandes
WHERE statut = 'payee'
GROUP BY DATE_TRUNC('month', date_commande);

Common decision errors

A technology does not compensate for an ambiguous business definition. Moving to a database must specify the level of detail, identifiers, rules and responsibilities.

• Migrate only because a file seems big, without understanding the uses.
• Keep several manual exports without owner or reference date.
• Build a base without a dictionary or rules, then reproduce the same inconsistencies.
• Giving direct write access to all users whereas a controlled application would be preferable.

Mini-diagnosis in one minute

Choose a real source. If it is modified by a single person, loosely connected, temporary and easy to verify, the spreadsheet may still be appropriate. If multiple processes write it, relationships must be valid, and an error affects operations, study a baseline.

The next step is to see how tables, keys and constraints transform these requirements into structure.