Erreurs typiques lors de la création et modification de tables

Salut, futurs pros de PostgreSQL ! Le sujet du jour, c'est sûrement l'une des compétences les plus précieuses en dev — éviter les erreurs. Bien sûr, tu ne pourras pas toutes les esquiver, surtout si tu débutes en SQL. Mais piger vite les erreurs classiques, c'est carrément faisable. C'est comme marcher dans une pièce sombre pleine de coins : tu te cognes deux-trois fois, mais après tu sais où sont les obstacles. Je vais t'aider à éviter les "coins qui font mal" quand tu crées ou modifies des tables.

Erreur 1 : Mauvais choix du type de données

Travailler avec les types de données, c'est comme choisir la bonne clé pour une serrure. Une "clé" (type de données) pas adaptée peut faire que ta table marche mal ou soit moins efficace.

Exemple d'erreur :

Tu veux créer une colonne pour stocker des numéros de téléphone et, par habitude, tu choisis le type INTEGER. Ça paraît logique, vu que les numéros sont des chiffres. Mais le souci, c'est que INTEGER ne convient pas pour des données qui :

• Commencent par zéro (0123456789 deviendra juste 123456789).
• Contiennent des caractères comme "+" ou des espaces.

-- Pas bon :
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number INTEGER -- Oups
);

-- Correct :
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number VARCHAR(15) -- Adapté à tous les formats de numéros
);

Comment éviter ça ?
Analyse bien la nature des données que tu vas stocker avant de choisir le type. Si t'as un doute, mate la doc officielle PostgreSQL sur les types de données.

Erreur 2 : Oublier les contraintes NOT NULL, CHECK, UNIQUE

Les contraintes servent à garder tes données propres. Si tu les oublies, c'est le bazar dans ta table, genre des valeurs vides là où il ne devrait pas y en avoir.

Exemple d'erreur : Tu crées une table pour stocker des étudiants, mais tu oublies que le nom et l'âge sont obligatoires.

-- Pas bon :
CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    age INTEGER
);

INSERT INTO students (name, age) VALUES (NULL, NULL); -- Euh, c'est quoi ça ?!

Version correcte :

CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL, -- Nom obligatoire
    age INTEGER CHECK (age > 0) -- Âge doit être positif
);

Comment éviter ça ?
Mets toujours des contraintes sur les champs obligatoires. C'est un peu comme une "protection" qui empêche les données foireuses de rentrer.

Erreur 3 : Problèmes d'unicité

Parfois tu peux oublier d'ajouter la contrainte d'unicité UNIQUE sur une colonne qui doit avoir des valeurs uniques. Résultat : des doublons.

Exemple d'erreur : Tu crées une table pour stocker des adresses mail, mais t'oublies de mettre UNIQUE.

-- Pas bon :
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100)
);

INSERT INTO users (email) VALUES ('user@example.com');
INSERT INTO users (email) VALUES ('user@example.com'); -- Ce mail existe déjà !

Version correcte :

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100) UNIQUE -- Emails uniques
);

Comment éviter ça ?
Mets toujours UNIQUE si les valeurs doivent être uniques. Si tu veux être plus flexible, tu peux utiliser CONSTRAINT avec un nom pour identifier la contrainte :

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100),
    CONSTRAINT unique_email UNIQUE (email)
);

Erreur 4 : Boulette lors de la modification des tables (ALTER TABLE)

Utiliser ALTER TABLE peut être piégeux, surtout si t'as déjà des données dans la table. Par exemple, tu peux oublier les valeurs autorisées dans une colonne, ce qui va causer des erreurs avec les données existantes.

Exemple d'erreur : Tu veux ajouter la contrainte NOT NULL sur une colonne existante, mais il y a déjà des valeurs NULL dedans.

-- Pas bon :
ALTER TABLE students ALTER COLUMN name SET NOT NULL; -- Erreur !

Si la table contient déjà des lignes avec NULL, PostgreSQL ne te laissera pas ajouter la contrainte.

Comment faire ?

Avant d'ajouter des contraintes, vérifie que les données sont ok. Par exemple :

UPDATE students SET name = 'Inconnu' WHERE name IS NULL;
ALTER TABLE students ALTER COLUMN name SET NOT NULL;

Erreur 5 : Supprimer des tables ou des données sans vérifier

Supprimer une table avec DROP TABLE ou des données avec DELETE — c'est irréversible. Donc avant de supprimer, vérifie toujours ce que tu fais.

Exemple d'erreur :

DROP TABLE courses; -- Oups, c'était pas la bonne table !

Comment éviter ça ?

Utilise la commande \dt dans psql pour voir les tables existantes et sois sûr de supprimer la bonne.

Ou alors utilise DROP TABLE IF EXISTS pour éviter les erreurs si tu veux supprimer une table qui n'existe pas :

DROP TABLE IF EXISTS courses;

Erreur 6 : Problèmes avec les tables temporaires

Les tables temporaires disparaissent à la fin de la session. Si tu essayes d'utiliser une table temporaire alors que la session est finie, tu vas avoir une erreur.

Exemple d'erreur :

CREATE TEMP TABLE temp_students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100)
);

-- Session terminée, et maintenant...
SELECT * FROM temp_students; -- Erreur : la table n'existe plus !

Comment éviter ça ?

Stocke les données temporaires à utiliser entre plusieurs sessions dans des tables normales, ou documente bien leur usage dans une seule session.

Erreur 7 : Oublier les contraintes pendant les tests

Souvent, en dev, tu peux zapper certaines contraintes en te disant "on verra plus tard". Mais en vrai, "plus tard" ça s'oublie vite.

Exemple d'erreur :

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50)
);

-- On insère des données :
INSERT INTO test_table (name) VALUES ('Nom en double');
INSERT INTO test_table (name) VALUES ('Nom en double'); -- Les soucis commencent...

Comment éviter ça ?

Crée direct tes tables avec les contraintes, même pour les tests :

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50) UNIQUE -- Ça t'évitera des maux de tête
);