Erreurs typiques lors de la gestion des données

Travailler avec une base de données, c’est un peu comme la vie d’un dev : plein de surprises. Même le dev le plus expérimenté peut se planter, genre supprimer des données par accident, essayer d’insérer un doublon ou casser des contraintes d’intégrité. Mais le plus important, c’est pas juste d’éviter ces erreurs, c’est aussi de savoir comment les réparer si jamais ça arrive. Allez, on va voir quelques-unes des erreurs les plus classiques.

Erreur n°1 : Oublier la condition WHERE

L’erreur la plus classique que font les débutants (et soyons honnêtes, même les devs expérimentés parfois), c’est d’oublier de mettre un WHERE dans une requête d’update ou de delete. Les requêtes sans WHERE mettent à jour ou suppriment toutes les lignes de la table.

-- Exemple à ne surtout pas faire :
UPDATE students SET status = 'diplômé';

-- Ou comme ça :
DELETE FROM students;

Conséquences : imagine que tu te rends compte après coup que ta table students, qui contenait toutes les infos sur les étudiants, est vide. Et le pire — impossible de récupérer les données si t’as pas de backup ou si t’utilisais pas les transactions (et même là, c’est déjà le stress).

Comment éviter : mets toujours des conditions dans tes requêtes UPDATE et DELETE pour bien cibler les lignes à modifier ou supprimer.

-- Voilà comment il faut faire :
UPDATE students
SET status = 'diplômé'
WHERE year_of_study = 4;

DELETE FROM students
WHERE status = 'exclu';

Un autre petit tips — avant de supprimer, lance toujours un SELECT pour vérifier que ta condition est bien calée :

-- On vérifie d’abord :
SELECT * FROM students WHERE status = 'exclu';

-- Ensuite on supprime :
DELETE FROM students WHERE status = 'exclu';

Erreur n°2 : Violation de l’unicité des données (UNIQUE)

Si ta table a une contrainte UNIQUE, toute tentative d’insérer un doublon va planter.

-- Erreur à cause d’un email en double :
INSERT INTO students (name, email) VALUES ('Otto Lin', 'otto.lin@email.com');
INSERT INTO students (name, email) VALUES ('Peter Pen', 'otto.lin@email.com');

Erreur :

ERROR: duplicate key value violates unique constraint "students_email_key"

Comment éviter : avant d’insérer, vérifie qu’il n’y a pas déjà une ligne avec la même valeur.

-- Une façon de faire :
SELECT * FROM students WHERE email = 'otto.lin@email.com';

-- Ou alors utiliser UPSERT :
INSERT INTO students (name, email)
VALUES ('Peter Pen', 'otto.lin@email.com')
ON CONFLICT (email) DO NOTHING;

Erreur n°3 : Violation des contraintes d’intégrité (FOREIGN KEY)

Imaginons que t’as deux tables : students et enrollments, où student_id dans enrollments est une clé étrangère vers id dans students. Si tu tentes d’insérer une ligne dans enrollments avec un student_id qui n’existe pas dans students, tu vas avoir une erreur.

INSERT INTO enrollments (student_id, course_id)
VALUES (999, 101); -- Erreur, car student_id 999 n’existe pas

Comment éviter ?

1. Vérifie toujours que la ligne existe dans la table parente avant d’insérer dans la table liée :

SELECT * FROM students WHERE id = 999;

2. Utilise la contrainte ON DELETE CASCADE pour que les lignes liées soient supprimées automatiquement quand tu supprimes dans la table parente (mais fais gaffe avec ça).

CREATE TABLE enrollments (
    id SERIAL PRIMARY KEY,
    student_id INT REFERENCES students(id) ON DELETE CASCADE,
    course_id INT
);

Erreur n°4 : Mauvais types de données

Quand tu insères ou mets à jour des données, PostgreSQL vérifie à fond la compatibilité des types. Si tu tentes de mettre une chaîne dans un champ numérique, ça va planter.

-- Erreur à cause d’un type incompatible :
INSERT INTO students (id, name) VALUES ('abc', 'Alex Go');

Erreur :

ERROR: invalid input syntax for type integer

Comment éviter ? Fais gaffe aux types de données que tu insères. Si les données viennent d’un formulaire utilisateur, valide-les côté appli.

Erreur n°5 : Problèmes d’accès concurrent (fuite de données)

Imagine deux utilisateurs qui essaient de modifier la même ligne en même temps. Sans isolation correcte des transactions, tu risques d’avoir des conflits.

-- Utilisateur A :
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

-- Utilisateur B :
BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;

Comment éviter ? Utilise les transactions et les niveaux d’isolation pour empêcher les modifs simultanées.

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

Erreur n°6 : Perte de données à cause de TRUNCATE

TRUNCATE supprime toutes les lignes d’une table sans retour possible, car cette commande ne supporte pas ROLLBACK (elle ne déclenche pas les triggers et s’exécute direct).

-- Supprime tout sans retour :
TRUNCATE TABLE students;

Comment éviter : préfère DELETE avec une condition à TRUNCATE si tu veux pouvoir annuler.

BEGIN;
DELETE FROM students WHERE year_of_study = 1;
-- Si tu changes d’avis :
ROLLBACK;

Erreur n°7 : Pas de transactions pour les opérations critiques

Si tu fais une opération complexe en plusieurs étapes et qu’une erreur survient au milieu, tes données peuvent se retrouver dans un état incohérent.

-- Étape 1 : on ajoute un étudiant
INSERT INTO students (name, email) VALUES ('Otto Lin', 'otto.lin@email.com');

-- Étape 2 : on l’inscrit à un cours
INSERT INTO enrollments (student_id, course_id) VALUES (LASTVAL(), 101); -- erreur

Comment éviter ? Mets tout ça dans une transaction :

BEGIN;

INSERT INTO students (name, email) VALUES ('Ivan Ivanov', 'ivan.ivanov@email.com');
INSERT INTO enrollments (student_id, course_id) VALUES (LASTVAL(), 101);

COMMIT;

Si une erreur arrive à n’importe quelle étape, tu peux tout annuler :

ROLLBACK;

Erreur n°8 : Gérer NULL n’importe comment

NULL réserve souvent des surprises, car il n’est égal ni à zéro, ni à une chaîne vide, et les comparaisons avec lui peuvent donner des résultats inattendus.

-- Ça ne marchera pas :
SELECT * FROM students WHERE email = NULL;

Comment éviter ? Utilise IS NULL ou IS NOT NULL :

SELECT * FROM students WHERE email IS NULL;

Les erreurs classiques, c’est inévitable, mais si tu sais les repérer et les éviter, tu pourras manipuler tes données en toute sécurité et efficacité. PostgreSQL, c’est un gardien strict mais juste de tes données, et il te renverra toujours une erreur si quelque chose cloche. Rappelle-toi juste : les erreurs, c’est pas des ennemis, c’est des profs.