Avantages et inconvénients de la normalisation

Aujourd'hui, on va encore une fois, mais cette fois plus en détail, s'arrêter sur un sujet super important : les avantages et inconvénients de la normalisation, histoire que tu piges mieux comment ces concepts s'appliquent dans la vraie vie. Alors, attache ta ceinture — c'est parti !

Élimination de la redondance des données

Quand les données dans une table ne sont pas normalisées, tu peux te retrouver avec la même info dupliquée dans plusieurs lignes. Par exemple, dans une table de commandes, l'adresse du client peut se répéter pour chaque commande. La normalisation vire ces duplicatas en mettant les infos communes dans des tables séparées.

Exemple :

-- Avant la normalisation
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_name TEXT,
    customer_address TEXT,
    order_date DATE
);

-- Après la normalisation
CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    customer_name TEXT,
    customer_address TEXT
);

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT REFERENCES customers(customer_id),
    order_date DATE
);

Pourquoi c'est important ? Moins de données dupliquées, ça veut dire moins de risques d'erreurs. Si l'adresse d'un client change, t'as juste à la mettre à jour à un seul endroit.

Assurer l'intégrité des données

Quand les données sont séparées dans des tables logiques, c'est plus simple de gérer leurs relations. Utiliser des clés étrangères aide à garder l'intégrité des données automatiquement. Par exemple, tu ne pourras pas supprimer par accident un client qui a encore des commandes dans la table des commandes.

Exemple :

-- La clé étrangère garantit que supprimer un client supprime aussi ses commandes liées
ALTER TABLE orders
ADD CONSTRAINT fk_customer FOREIGN KEY (customer_id)
REFERENCES customers(customer_id)
ON DELETE CASCADE;

Tu peux être sûr que la structure de la base ne laissera pas apparaître de "données orphelines".

Simplification des mises à jour

Quand ta base est normalisée, les updates deviennent faciles et moins sujets aux bugs. Reprenons l'exemple des clients — si un client change d'adresse, tu modifies juste sa ligne dans une seule table. Dans des tables non normalisées, tu risques d'oublier de changer l'adresse dans certaines lignes, ce qui crée de l'incohérence.

Minimisation des anomalies

Anomalies d'insertion : dans une table non normalisée, tu peux te retrouver coincé à ne pas pouvoir ajouter une ligne sans info inutile. Par exemple, tu ne peux pas ajouter une commande tant que tu ne connais pas le nom du client.

Anomalies de mise à jour : des erreurs peuvent arriver lors des updates. Par exemple, si tu changes le nom d'un client dans une ligne, il peut rester l'ancien nom dans une autre.

Anomalies de suppression : supprimer une ligne peut faire perdre des infos importantes. Par exemple, supprimer une commande supprime aussi le nom du client si tout est stocké dans la même table.

Réduction du volume de données

La normalisation réduit souvent la taille de la base, vu qu'elle enlève les doublons. C'est super important quand tu stockes de gros volumes d'infos.

Inconvénients de la normalisation

1. Complexité de la structure de la base

Avec le temps, la normalisation peut rendre la structure de la base super complexe, avec des milliers (!) de tables reliées. Du coup, pour choper des données qui étaient avant dans une seule table, tu dois écrire des requêtes SQL bien velues avec plein de JOIN.

Exemple de complexité :

-- Requête pour obtenir les infos des commandes avec détails sur les produits et catégories
SELECT
    o.order_id,
    o.order_date,
    c.customer_name,
    p.product_name,
    cat.category_name,
    oi.quantity,
    oi.unit_price
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
JOIN categories cat ON p.category_id = cat.category_id;

Si le nombre de tables et de relations augmente, le temps d'exécution des requêtes peut exploser.

2. Baisse de performance avec des JOIN fréquents

Faire souvent des JOIN peut coûter cher en ressources, surtout si les tables sont grosses et sans index. Dans les systèmes analytiques où les requêtes traitent des millions de lignes, la normalisation peut vraiment plomber la perf.

3. Besoin d'opérations en plus pour la dénormalisation

Si la structure normalisée sert à de l'analytics, il faut parfois la dénormaliser temporairement pour accélérer les requêtes analytiques. Ça peut vouloir dire créer des vues (VIEW) ou des tables d'agrégation.

Exemple :

-- Vue dénormalisée pour l'analytics
CREATE VIEW orders_with_customers AS
SELECT
    o.order_id,
    o.order_date,
    c.customer_name,
    c.customer_address
FROM
    orders o
JOIN
    customers c ON o.customer_id = c.customer_id;

4. Barrière à l'entrée élevée

Pour les débutants, la normalisation peut sembler compliquée. Au lieu d'une seule table avec toutes les données, tu dois jongler avec plusieurs tables et piger leurs relations. Ça peut ralentir le dev, surtout si l'équipe n'est pas super calée en bases de données.

5. Parfois la redondance, c'est utile

Dans les vrais projets, parfois c'est plus rentable de garder des données redondantes pour booster la perf. Par exemple, si ton appli utilise souvent des données qu'on ne peut choper qu'avec des JOIN compliqués, c'est mieux de les stocker dans une seule table.