Choisir un type de données, c’est un peu comme choisir le bon outil pour bricoler. Tu ne vas pas utiliser un tournevis pour planter un clou (enfin j’espère). Pareil en base de données : le bon type de données, ça change tout pour la perf, la mémoire et la gestion des données. Par exemple, si tu stockes de l’argent en REAL, tu risques d’avoir des soucis de précision, et utiliser TEXT au lieu de VARCHAR pour des petites chaînes, ça bouffe plus de mémoire pour rien.
Quand tu choisis un type de données, pense à plusieurs trucs :
Nature des données
Détermine à quelle catégorie appartiennent tes données : nombres, chaînes, booléens, dates ou un truc plus complexe genre des structures JSON.
Volume des données
Tu comptes stocker combien de données ? Par exemple, pour des textes jusqu’à 50 caractères, mieux vaut prendre VARCHAR(50) plutôt que TEXT.
Précision et plage
Tu as besoin d’une grosse précision (genre pour des calculs financiers) ? Tu veux limiter la plage des valeurs ?
Fréquence et type de requêtes
Tu vas souvent accéder à ces données ? Sache que les types complexes comme JSONB demandent plus de ressources à traiter.
Exemples de choix de types de données
Chaque type de données, c’est une mission différente. Parfois il faut la précision au centime près, parfois il faut juste que tout rentre. Voilà quelques exemples pour choisir le bon type selon la situation.
Données financières
Quand il s’agit de stocker de l’argent, comme en compta, pas le droit à l’erreur. Le meilleur choix, c’est le type NUMERIC, super précis. Par exemple, on veut une table avec ces colonnes :
| Nom de la colonne | Type de données | Commentaire |
|---|---|---|
| id | SERIAL | Clé primaire |
| amount | NUMERIC(10, 2) | Dix chiffres dont deux après la virgule |
| currency_code | CHAR(3) | Code ISO de la monnaie, genre "USD", "EUR" |
| transaction_date | TIMESTAMP | Date de la transaction, par défaut — l’heure actuelle |
Pourquoi pas REAL ? Parce que les nombres à virgule flottante peuvent perdre en précision, et ça c’est chaud pour la finance.
Données textuelles
Si tu veux stocker des noms d’utilisateurs, des adresses ou n’importe quelle chaîne, mets toujours une longueur max quand tu peux. Genre VARCHAR(50) au lieu de TEXT. Ça évite des bugs et ça optimise la mémoire.
| Nom de la colonne | Type de données | Commentaire |
|---|---|---|
| id | SERIAL | Clé primaire |
| username | VARCHAR(50) | Login de l’utilisateur, unique et obligatoire |
| VARCHAR(255) | ||
| bio | TEXT | Bio, genre un texte bien long |
Si la longueur de la chaîne est vraiment fixe (genre les codes pays à deux lettres), utilise CHAR :
| Nom de la colonne | Type de données | Commentaire |
|---|---|---|
| code | CHAR(2) | Code ISO du pays (genre "US"), clé primaire |
| name | VARCHAR(100) | Nom du pays, obligatoire |
Données de type timestamp
Pour stocker des dates d’événements ou des plannings, le plus souvent TIMESTAMP fait le taf, car il contient à la fois la date et l’heure.
| Nom de la colonne | Type de données | Commentaire |
|---|---|---|
| id | SERIAL | Clé primaire |
| event_name | VARCHAR(100) | Nom de l’événement |
| start_time | TIMESTAMP | Heure de début de l’événement, obligatoire |
| end_time | TIMESTAMP | Heure de fin de l’événement, obligatoire |
Si tu veux juste l’heure sans la date, prends TIME, et si tu veux juste la date sans l’heure — DATE.
Identifiants uniques
Quand tu dois générer des identifiants vraiment uniques partout, utilise UUID. Par exemple, pour générer un identifiant unique de transaction :
| Nom de la colonne | Type de données | Commentaire |
|---|---|---|
| request_id | UUID | Identifiant unique de la requête, généré par défaut avec gen_random_uuid() |
| endpoint | VARCHAR(255) | Adresse de l’endpoint API appelé |
| timestamp | TIMESTAMP | Date de la requête, par défaut — l’heure actuelle |
JSONB : structures complexes
Quand tu dois stocker des données dont la structure peut changer ou être complexe, genre des préférences utilisateur ou des métadonnées, utilise JSONB.
| Nom de la colonne | Type de données | Commentaire |
|---|---|---|
| user_id | SERIAL | Clé primaire (ID utilisateur) |
| preferences | JSONB | Préférences utilisateur au format JSON |
Le JSONB c’est pratique, mais fais gaffe, ça peut ralentir si tu fais plein d’inserts/updates.
Tableaux
Les tableaux sont cool si tu veux stocker des listes de données du même type. Par exemple, une liste de tags :
| Nom de la colonne | Type de données | Commentaire |
|---|---|---|
| id | SERIAL | Clé primaire |
| title | VARCHAR(255) | Titre de l’article |
| tags | TEXT[] | Tableau de tags |
Résumé des types de données par tâche
| Type de tâche | Type de données recommandé | Exemple |
|---|---|---|
| Identifiant d’enregistrement | SERIAL, BIGSERIAL, UUID |
id SERIAL PRIMARY KEY |
| Quantité, entiers | INTEGER, BIGINT |
quantity INTEGER |
| Calculs financiers | NUMERIC |
price NUMERIC(10, 2) |
| Stockage de chaînes | VARCHAR(n), TEXT |
username VARCHAR(50) |
| Chaînes fixes courtes | CHAR(n) |
status CHAR(1) |
| Dates et heures | DATE, TIME, TIMESTAMP |
created_at TIMESTAMP DEFAULT NOW() |
| Identifiants uniques | UUID |
id UUID PRIMARY KEY DEFAULT gen_random_uuid() |
| Structures complexes (JSON) | JSONB |
metadata JSONB |
| Listes de valeurs | ARRAY |
tags TEXT[] |
| Valeur booléenne | BOOLEAN |
is_active BOOLEAN |
Tu connais sûrement déjà tous les types sauf SERIAL. En fait, SERIAL c’est juste un INTEGER qui sert d’identifiant pour les lignes dans les tables.
Il s’incrémente tout seul de 1 à chaque fois que tu ajoutes une nouvelle ligne. Donc si tu ajoutes 10 lignes, la première aura id = 1, la deuxième = 2, etc. On verra tout ça en détail dans la prochaine leçon :)
GO TO FULL VERSION