CodeGym /Cours /SQL SELF /Changer les types de données des colonnes

Changer les types de données des colonnes

SQL SELF
Niveau 18 , Leçon 1
Disponible

Imagine, tu crées une table d’étudiants pour une université. Encore une fois ! :)

Au début, tu décides que le champ pour l’âge age sera un entier et tu mets le type SMALLINT (ça marche pour les nombres de -32,768 à 32,767). Mais avec le temps, ta base de données grandit, et tu ajoutes des infos sur des étudiants d’autres pays qui indiquent leur âge… en jours depuis la naissance ! Là, ton SMALLINT devient trop petit — il est temps de passer, par exemple, à INTEGER.

Voilà encore quelques cas classiques où tu dois changer le type de données :

  1. Augmenter ou réduire la plage des nombres.
  2. Changer la longueur des chaînes (genre de VARCHAR(50) à VARCHAR(100)).
  3. Passer à un autre type de données pour optimiser (par exemple, convertir TEXT en VARCHAR).
  4. Erreur dans le choix initial du type de colonne (genre t’as mis BOOLEAN au lieu de INTEGER).

Syntaxe de la commande pour changer le type de données

Dans PostgreSQL, tu changes le type de données d’une colonne avec la commande ALTER TABLE. Ça te permet d’adapter la structure de ta table à de nouveaux besoins.

ALTER TABLE table_name
ALTER COLUMN column_name TYPE new_data_type;

C’est tout simple : tu mets le nom de la table, la colonne que tu veux modifier, et le nouveau type de données.

Exemple 1 : Passer de INTEGER à BIGINT

Imaginons qu’on a une table d’étudiants :

CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    age INTEGER
);

Tout allait bien tant que l’âge ne dépassait pas quelques millions d’années (ne demande pas pourquoi, c’est juste un exemple !). Pour rassurer PostgreSQL, on va changer le type de la colonne age de INTEGER à BIGINT :

ALTER TABLE students
ALTER COLUMN age TYPE BIGINT;

Exemple 2 : Augmenter la longueur d’une chaîne

Tu as créé une table pour stocker les cours et tu as mis que leurs noms feraient jusqu’à 50 caractères :

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

Mais tu te rends compte que les noms de cours sont bien plus longs et compliqués que prévu. Facile à régler :

ALTER TABLE courses
ALTER COLUMN name TYPE VARCHAR(150);

Exemple 3 : Conversion de types

Disons qu’on avait une table où le champ birth_date était du texte :

CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    birth_date TEXT
);

Tu te rends compte que bosser avec des dates au format TEXT c’est pas top, parce que tu peux pas filtrer ou trier facilement. La solution ? On convertit TEXT en DATE :

ALTER TABLE employees
ALTER COLUMN birth_date TYPE DATE USING birth_date::DATE;

Regarde bien la partie USING birth_date::DATE. Ça dit à PostgreSQL qu’il faut convertir les données avant de changer le type.

Pourquoi parfois il faut une conversion explicite des données ?

Quand PostgreSQL doit changer un type, il essaie de convertir automatiquement les données existantes vers le nouveau type. Si c’est pas possible, tu as une erreur. Par exemple, changer un champ TEXT en INTEGER sans dire comment interpréter les données texte, ça va planter.

Exemple de problème

ALTER TABLE employees
ALTER COLUMN birth_date TYPE DATE;
-- Erreur : impossible de convertir la valeur 'not a date' en type DATE.

Mais t’inquiète, il y a une solution. Ajoute une conversion explicite avec USING :

ALTER TABLE employees
ALTER COLUMN birth_date TYPE DATE USING to_date(birth_date, 'YYYY-MM-DD');

Ici on utilise la fonction to_date() pour convertir les chaînes en dates.

La commande USING

Dans PostgreSQL, quand tu changes le type d’une colonne avec ALTER TABLE ... ALTER COLUMN ... TYPE, parfois tu dois indiquer comment convertir les données existantes — et là tu utilises le mot-clé USING.

Syntaxe :

ALTER TABLE table_name
ALTER COLUMN column_name TYPE new_data_type
USING expression;

Explication :

  • USING te permet de préciser la formule de conversion des valeurs de l’ancien type vers le nouveau.
  • C’est super utile quand la conversion automatique est impossible ou ambiguë.

Exemple simple : chaîne → nombre

ALTER TABLE users
ALTER COLUMN age TYPE INTEGER
USING age::INTEGER;

Ici age était au départ de type TEXT, et on veut le convertir en INTEGER. USING age::INTEGER — conversion explicite de type.

Exemple : texte → date

ALTER TABLE events
ALTER COLUMN event_date TYPE DATE
USING TO_DATE(event_date, 'YYYY-MM-DD');

Si event_date était du texte genre '2023-10-25', on dit à PostgreSQL comment le transformer en type DATE.

Quand USING est obligatoire ?

  • Quand il n’y a pas de conversion directe de type.
  • Quand tu dois transformer les données.
  • Quand les types sont incompatibles (TEXTBOOLEAN, VARCHARINTEGER, etc.).

Erreurs courantes quand tu changes les types de données

Erreur si tu ne convertis pas les données. Si les données ne peuvent pas être converties automatiquement, tu dois absolument préciser la conversion avec USING.

ALTER TABLE employees
ALTER COLUMN birth_date TYPE DATE;
-- Erreur : la colonne 'birth_date' contient des valeurs invalides pour le type DATE

L’opération bloque la table. Sache que changer le type de données peut bloquer la table en écriture jusqu’à la fin de l’opération. C’est super important pour les grosses tables. Prévois les changements pendant les périodes creuses.

Problèmes avec les tables liées et les clés étrangères. Si la colonne fait partie d’une clé étrangère, changer son type peut être plus compliqué. PostgreSQL va demander de recréer les clés étrangères.

Astuces utiles

Vérifie toujours les données actuelles. Utilise des requêtes comme SELECT DISTINCT column_name avant de changer le type, pour voir si tu peux convertir les données sans souci.

Teste les changements. Crée une copie temporaire de la table et fais des essais dessus avant de toucher à la vraie table. Par exemple :

CREATE TEMP TABLE temp_students AS SELECT * FROM students;

N’oublie pas USING. C’est ton sauveur quand tu changes radicalement de type (genre TEXTNUMERIC).

Maintenant tu sais comment changer le type de données d’une colonne dans PostgreSQL. J’espère que la prochaine fois que tu devras revoir la structure de tes données, tu seras au taquet. Les tables sont malignes, mais même elles ont parfois besoin d’un upgrade !

Commentaires
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION