data / sql

Tables et types de données

Leçon 11 exercice

Explication

Un peu d'histoire

SQL repose sur le modèle relationnel, inventé par Edgar F. Codd, chercheur chez IBM, dans un article publié en 1970. Le langage SQL lui-même est développé au milieu des années 1970 par deux autres chercheurs d'IBM, Donald Chamberlin et Raymond Boyce, sous le nom initial de SEQUEL (Structured English Query Language), renommé SQL par la suite pour des raisons de marque déposée. Il est standardisé par l'ANSI en 1986.

Pourquoi apprendre SQL aujourd'hui

Plus de 50 ans après l'invention du modèle relationnel, SQL reste le langage universel pour interroger des données structurées : la quasi-totalité des entreprises, quelle que soit leur taille, stockent une partie critique de leurs données dans des bases relationnelles comme PostgreSQL, MySQL ou SQL Server. Contrairement à beaucoup de technologies qui se démodent vite, SQL est une compétence transversale et durable, utile aussi bien à un développeur backend qu'à un data analyst ou un ingénieur DevOps.

Ce que vous allez apprendre

Distinguer une table, une ligne et une colonne dans le modèle relationnel
Choisir le bon type de données selon la nature de l'information à stocker
Comprendre pourquoi FLOAT est dangereux pour représenter de l'argent
Utiliser DECIMAL/NUMERIC pour toute valeur monétaire exacte
Modifier une table existante avec ALTER TABLE sans perdre de données

Dans quel contexte ?

Imagine une équipe qui développe le back-office d'une boutique en ligne. Elle doit créer une table produits avec un prix, un stock et une date de mise en vente. Le choix du type de chaque colonne, fait dès le premier jour, conditionne toute la fiabilité des calculs de chiffre d'affaires réalisés des mois plus tard : une erreur de type sur la colonne prix peut fausser silencieusement des milliers de rapports financiers.

Étape 1 : imaginer un classeur d'entreprise

Avant tout vocabulaire technique, imagine un immense classeur d'entreprise. Chaque intercalaire regroupe des fiches d'un même genre : "clients" d'un côté, "produits" de l'autre. Une base relationnelle numérise exactement cette idée.

Étape 2 : donner un nom précis à chaque niveau

Cet intercalaire, c'est une table. Chaque fiche individuelle à l'intérieur (un client précis) est une ligne. Et chaque fiche a toujours les mêmes champs à remplir — nom, email, date de naissance — ce sont les colonnes. Trois niveaux, trois mots à retenir.

Étape 3 : le problème qui surgit sans règles

Maintenant, imagine que rien n'oblige à remplir ces champs de façon cohérente. Une personne écrit une date "12/03/2024", une autre "2024-03-12". Très vite, plus personne ne peut trier ou comparer ces fiches correctement.

Étape 4 : le type de données comme garde-fou

C'est exactement le rôle du type de données (entier, texte, décimal, date...). En le déclarant une fois pour toutes sur une colonne, on garantit que chaque valeur stockée aura toujours la même forme, vérifiable et calculable par la base.

Type SQL	Utilisation	Exemple concret
`INTEGER` / `BIGINT`	Nombres entiers	`stock`, `age`, `id`
`DECIMAL(10,2)` / `NUMERIC`	Argent, valeurs exactes	`prix = 19.99`
`FLOAT` / `DOUBLE`	Calculs scientifiques approximatifs	mesures physiques
`VARCHAR(n)`	Texte court de longueur limitée	`email VARCHAR(255)`
`TEXT`	Texte long, sans limite fixe	description d'article
`DATE` / `TIMESTAMP`	Dates, dates+heure	`date_naissance`, `cree_le`
`BOOLEAN`	Vrai/faux	`est_actif`

Étape 5 : un piège précis à connaître dès maintenant

Il existe une erreur très fréquente chez les débutants : stocker un prix en FLOAT. Ce type représente les nombres en binaire de façon approximative, si bien que 0.1 + 0.2 ne donne pas exactement 0.3.

Piège fréquent

CREATE TABLE produits (prix FLOAT) semble fonctionner en test, mais après des milliers de lignes cumulées, les totaux calculés avec SUM(prix) peuvent dériver de plusieurs centimes par rapport à la réalité comptable. Ce genre de bug est très difficile à détecter a posteriori.

Étape 6 : la bonne pratique pour l'argent

Pour tout ce qui touche à l'argent, il faut donc préférer un type à précision exacte comme DECIMAL ou NUMERIC. Ce n'est pas un détail cosmétique : une minuscule erreur d'arrondi répétée des millions de fois peut coûter cher en production.

Bonne pratique

Choisis toujours DECIMAL(10, 2) pour un prix en euros (2 chiffres après la virgule) plutôt que FLOAT. Beaucoup d'équipes préfèrent même stocker les montants en centimes dans un BIGINT (prix_centimes) pour éliminer tout risque d'arrondi.

Et la suite ?

Une fois ces quatre notions posées (table, ligne, colonne, type), tu as tout ce qu'il faut pour aborder la prochaine leçon : interroger ces données avec SELECT. Plus tard, en leçon 8, tu verras comment renforcer encore ces types avec de vraies contraintes.

Commandes & code

Tables et types de données

Une base relationnelle stocke les données dans des tables composées de colonnes typées.

-- Création d'une table de base
CREATE TABLE utilisateurs (
    id            INTEGER PRIMARY KEY,      -- identifiant unique
    email         VARCHAR(255) NOT NULL,    -- chaîne de longueur variable, limitée
    nom           TEXT,                     -- chaîne de longueur illimitée
    age           INTEGER,                  -- nombre entier
    solde         DECIMAL(10, 2),           -- nombre décimal exact (précision monétaire)
    note_moyenne  FLOAT,                    -- nombre à virgule flottante (imprécis)
    est_actif     BOOLEAN DEFAULT TRUE,     -- vrai/faux
    cree_le       TIMESTAMP DEFAULT CURRENT_TIMESTAMP,  -- date + heure
    date_naissance DATE,                    -- date seule
    heure_connexion TIME,                   -- heure seule
    metadata      JSON                      -- données semi-structurées (PostgreSQL/MySQL)
);

-- Types numériques courants
CREATE TABLE produits (
    id           SERIAL PRIMARY KEY,   -- PostgreSQL : entier auto-incrémenté
    prix_centimes BIGINT,              -- grand entier (évite les erreurs d'arrondi flottant)
    stock        SMALLINT,             -- petit entier, économe en espace
    poids_kg     NUMERIC(6, 3)         -- ex: 123.456 kg, précision exacte
);

-- Inspecter la structure d'une table
-- PostgreSQL
\d utilisateurs

-- Standard SQL / MySQL
DESCRIBE utilisateurs;
SHOW COLUMNS FROM utilisateurs;

-- Supprimer / modifier une table
DROP TABLE IF EXISTS utilisateurs;
ALTER TABLE utilisateurs ADD COLUMN telephone VARCHAR(20);
ALTER TABLE utilisateurs DROP COLUMN telephone;
ALTER TABLE utilisateurs RENAME COLUMN nom TO nom_complet;
ALTER TABLE utilisateurs ALTER COLUMN age TYPE SMALLINT;  -- PostgreSQL

Résumé

INTEGER/BIGINT/SMALLINT pour les entiers, DECIMAL/NUMERIC pour l'argent (précision exacte).
FLOAT/DOUBLE sont approximatifs : à éviter pour des montants.
VARCHAR(n) limite la longueur, TEXT ne la limite pas.
TIMESTAMP, DATE, TIME pour le temps ; JSON pour du semi-structuré.
ALTER TABLE modifie une table existante sans perte de données (en général).

Exercices pratiques

1 disponible

Mission : fiabiliser le schéma d'une boutique en ligne avant l'audit comptable

Objectif : Diagnostiquer un mauvais choix de type sur une colonne monétaire et corriger le schéma avant que l'erreur ne fausse les rapports financiers.

Contexte

Tu reprends la table produits d'une boutique en ligne créée par un stagiaire. La colonne prix a été déclarée en FLOAT, et le total de chiffre d'affaires calculé avec SUM(prix) ne correspond jamais exactement aux relevés comptables envoyés par la compta. L'audit de fin de trimestre a lieu dans deux jours : tu dois diagnostiquer le problème et corriger le schéma.

Résoudre l’exercice →