Décision : choisir le bon type de données
Le choix d'un type de données est l'une des décisions les plus coûteuses à corriger ensuite : un mauvais type produit des résultats erronés (par ex. float pour de l'argent), de l'espace gaspillé et des requêtes lentes. Cet arbre vous oriente vers le bon type pour les champs numériques, texte, date/heure, clé (PK), semi-structurés (JSON) et catégories (ENUM), et met en évidence les pièges classiques comme l'argent et les jeux de caractères.
Quel type de données stockez-vous ?
Le bon type est déterminé par la nature des données. Dans quelle catégorie entre le champ : un nombre, du texte, une date/heure, la clé primaire de la table, des données flexibles/semi-structurées (JSON) ou un ensemble limité de catégories ?
- Valeur numérique (quantité, argent, mesure, compteur)
- Texte (nom, description, code)
- Date et/ou heure
- Je conçois une clé primaire (PK)
- Champs flexibles/imbriqués/variables (données semi-structurées)
- Un ensemble limité et connu de catégories (statut, type, priorité)
Le nombre est-il un entier ou un décimal — et s'agit-il d'argent ?
Pour les numériques, la distinction la plus critique est l'exactitude. La valeur est-elle un entier (quantité, ID, compteur) ou un décimal ? Si décimal, s'agit-il d'ARGENT/d'un montant financier ? La virgule flottante binaire (FLOAT/DOUBLE) n'est jamais utilisée pour l'argent ni partout où l'exactitude est requise, car elle produit des erreurs d'arrondi.
- Entier (quantité, compteur, id)
- Argent ou décimal exact (prix, solde, taux)
Recommandation : entier (SMALLINT / INT / BIGINT)
Pour les entiers, choisissez le plus petit type couvrant la plage requise. Un type inutilement grand gaspille de l'espace et de la taille d'index ; mais pour les champs susceptibles de croître, comme les compteurs/PK, une largeur suffisante est indispensable pour éviter le débordement.
Recommandation : NUMERIC / DECIMAL — JAMAIS FLOAT pour l'argent
Pour l'argent et les décimaux exacts, utilisez NUMERIC/DECIMAL à virgule fixe (exacts). FLOAT/DOUBLE sont à virgule flottante binaire et ne peuvent pas stocker exactement des valeurs comme 0.1 ; additions/multiplications produisent des dérives de centimes, des soldes erronés et des problèmes d'audit.
Recommandation : texte — VARCHAR vs TEXT vs CHAR
Pour le texte, VARCHAR/TEXT s'utilisent pour une longueur variable et CHAR pour une longueur réellement fixe. Dans les moteurs modernes, la différence de stockage entre VARCHAR et TEXT est le plus souvent négligeable ; la vraie décision est d'imposer ou non une limite sémantique (contrainte de longueur).
Recommandation : date/heure — TIMESTAMP avec fuseau horaire
Si vous stockez un instant (heure d'un événement), choisissez un type tenant compte du fuseau horaire. Stocker sans fuseau horaire conduit à des calculs et comparaisons erronés entre régions/lors des changements d'heure.
Recommandation : clé primaire — BIGINT vs UUID
Il existe deux options principales pour une PK : un nombre croissant (BIGINT identity/sequence) ou un UUID. Une PK numérique est petite et favorable à l'index, mais prévisible et nécessite une génération centralisée ; un UUID peut être généré de façon distribuée mais est plus volumineux et son ordre aléatoire peut nuire à l'index.
Recommandation : JSON / JSONB — avec modération
Le type JSON est puissant pour les champs à schéma flexible, imbriqués ou clairsemés ; mais la discipline relationnelle (contraintes, index, sûreté de typage) peut se perdre. Règle : placez les champs fixes et fréquemment interrogés dans des colonnes normales, ne gardez en JSON que la partie réellement variable.
Recommandation : ENUM vs table de référence (lookup)
Il existe deux options pour des ensembles de catégories limités : le type ENUM du moteur, ou une table de référence + clé étrangère. ENUM est compact et simple, mais ajouter une valeur exige une modification de schéma ; une table de référence est flexible et peut porter des attributs supplémentaires (description, indicateur actif, ordre).