Erreurs typiques avec les foreign keys

On est tous humains, et on fait tous des erreurs. Surtout quand il s'agit des subtilités des foreign keys dans les bases de données. Dans ce cours, je vais t'aider à éviter les pièges et les erreurs les plus fréquentes. Une bonne base de données, c'est comme un pont solide : si tu fais une erreur quelque part, tout peut s'écrouler. Allez, voyons comment garder tes "ponts de données" en bon état.

Erreur 1 : Pas d'index sur la foreign key

Quand tu ajoutes une foreign key, tu dis à la base : "Relie ces tables entre elles". Mais si tu ne crées pas explicitement d'index sur cette foreign key, les requêtes complexes sur les tables liées peuvent devenir super lentes.

Exemple du problème :

CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

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

À première vue, tout a l'air nickel : les tables sont là, la foreign key aussi. Mais si tu fais une requête comme :

SELECT * 
FROM orders 
JOIN customers ON orders.customer_id = customers.customer_id;

eh bien, avec beaucoup de données, cette requête peut être super lente, parce que PostgreSQL ne trouvera pas d'index pour optimiser le join.

Comment éviter :

Crée toujours un index sur la colonne référencée par la foreign key. Parfois PostgreSQL le fait tout seul, mais mieux vaut assurer le coup.

CREATE INDEX idx_customer_id ON orders(customer_id);

Erreur 2 : Mauvaise séquence de création des tables

Imagine que tu crées tes tables, mais tu essaies d'ajouter une foreign key avant que la table référencée n'existe. PostgreSQL va râler et balancer des erreurs, parce qu'il ne trouve pas la table cible.

Exemple du problème :

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

-- Oups, où est la table customers ?..
CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

Résultat : PostgreSQL balance une erreur, car la table customers n'existe pas encore.

Comment éviter :

Crée d'abord les tables référencées, puis ajoute les foreign keys. L'ordre compte ! Voilà la bonne façon :

CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

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

Erreur 3 : Fautes de syntaxe dans les opérations en cascade

Les foreign keys sont souvent accompagnées d'options comme ON DELETE CASCADE ou ON UPDATE RESTRICT. Mais si tu oublies de bien écrire ces règles, ta base peut se comporter bizarrement. Par exemple, supprimer des données dans une table ne va rien faire dans les tables dépendantes.

Exemple du problème :

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT REFERENCES customers(customer_id) ON DELETE CASCADEE
);

Un œil attentif verra la faute de frappe — le mot CASCADEE est mal écrit. PostgreSQL ne laissera pas passer ça.

Comment éviter :

Bien écrire, c'est déjà la moitié du boulot. Si t'as un doute, checke toujours la doc officielle PostgreSQL.

Erreur 4 : Violation de l'intégrité des données

L'intégrité des données, c'est sacré dans une base, et les foreign keys sont là pour ça. Mais parfois, on oublie de mettre une foreign key, et tout part en vrille.

Exemple du problème :

CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT
);

-- On insère des données
INSERT INTO orders (customer_id) VALUES (999);

Là, on a ajouté une commande pour un client qui n'existe pas. Ça casse l'intégrité des données, et cette commande va "flotter".

Comment éviter :

Utilise toujours des foreign keys pour éviter qu'une table pointe vers des enregistrements inexistants. Voilà la version correcte :

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

Maintenant, si tu essaies d'insérer une "commande orpheline", tu auras une erreur.

Erreur 5 : Masquer les erreurs de foreign key

Parfois, les devs essaient de forcer l'insertion de données incompatibles avec INSERT ... ON CONFLICT. Ça peut sembler cool, mais avec les foreign keys, ça peut donner des résultats chelous.

Exemple du problème :

INSERT INTO orders (order_id, customer_id)
VALUES (1, 999)
ON CONFLICT DO NOTHING;

Résultat : rien n'est inséré, mais la base ne te dit pas pourquoi. Tu perds le contrôle.

Comment éviter :

Si tu utilises ON CONFLICT, vérifie toujours tes données avant. Par exemple :

INSERT INTO orders (order_id, customer_id)
SELECT 1, 999
WHERE EXISTS (
    SELECT 1 FROM customers WHERE customer_id = 999
);

Erreur 6 : Suppression de lignes dépendantes sans ON DELETE

Si tu supprimes une ligne dans la table référencée par une foreign key, mais que t'as pas mis ON DELETE CASCADE, les lignes dépendantes restent, ce qui casse la logique des liens.

Exemple du problème :

DELETE FROM customers WHERE customer_id = 1;
-- Les lignes dans orders avec customer_id = 1 sont toujours là.

Comment éviter :

Ajoute ON DELETE CASCADE pour que les lignes liées soient supprimées automatiquement :

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT REFERENCES customers(customer_id) ON DELETE CASCADE
);

Maintenant, quand tu supprimes un client, ses commandes disparaissent aussi.

Erreur 7 : Galères avec les relations MANY-TO-MANY

Quand tu bosses avec des relations MANY-TO-MANY, on oublie parfois de mettre une clé primaire composée ou un index sur la table d'association.

Exemple du problème :

CREATE TABLE enrollments (
    student_id INT REFERENCES students(student_id),
    course_id INT REFERENCES courses(course_id)
);

-- Oups ! On a oublié le PRIMARY KEY.

Comment éviter :

Ajoute une clé primaire composée ou un index unique :

CREATE TABLE enrollments (
    student_id INT REFERENCES students(student_id),
    course_id INT REFERENCES courses(course_id),
    PRIMARY KEY (student_id, course_id)
);

Erreur 8 : Références cycliques

Les références cycliques arrivent quand deux tables se référencent mutuellement avec des foreign keys. Ça crée une boucle et pose problème à l'insertion des données.

Exemple du problème :

CREATE TABLE table_a (
    id SERIAL PRIMARY KEY,
    table_b_id INT REFERENCES table_b(id)
);

CREATE TABLE table_b (
    id SERIAL PRIMARY KEY,
    table_a_id INT REFERENCES table_a(id)
);

Comment éviter :

Utilise DEFERRABLE INITIALLY DEFERRED pour que PostgreSQL vérifie l'intégrité à la fin de la transaction :

CREATE TABLE table_a (
    id SERIAL PRIMARY KEY,
    table_b_id INT REFERENCES table_b(id) DEFERRABLE INITIALLY DEFERRED
);

Les erreurs avec les foreign keys ne ralentissent pas seulement le dev, elles peuvent aussi causer de vrais soucis de données. Utilise cette liste comme pense-bête pour éviter les pièges classiques. Rappelle-toi : la foreign key, c'est ton pote, pas ton ennemi. Le principal, c'est de bien l'utiliser, et ta base sera un socle solide pour ton projet sur le long terme.