Types de données MySQL expliqués : choisissez les bons types de colonnes pour la performance et l’évolutivité

1. Introduction : Pourquoi vous devriez comprendre la liste des types de données MySQL

Lorsque vous concevez des tables ou intégrez des applications avec MySQL, l’une des questions les plus courantes est : « Quel type de données dois-je utiliser pour cette colonne ? »
Doit-ce être INT ? Avez-vous vraiment besoin de BIGINT ? VARCHAR est-il suffisant pour les chaînes de caractères, ou TEXT est-il préférable ? Ces choix peuvent sembler mineurs, mais ils forment la base qui affecte votre système plus tard.

Si vous sous-estimez la façon de choisir les types de données, vous rencontrerez souvent des problèmes comme les suivants :

• À mesure que vos données croissent au-delà des attentes, vous gaspillez de l’espace de stockage
• Les index gonflent et les performances des requêtes se dégradent progressivement
• Des valeurs hors limites ou des débordements causent des bogues ou des exceptions inattendus
• Vous êtes obligé de changer les types de colonnes plus tard, déclenchant une migration à grande échelle

En d’autres termes, comprendre systématiquement les types de données MySQL et choisir le bon pour chaque cas d’utilisation est la façon la plus rapide d’améliorer à la fois les performances et la maintenabilité.

Cette page est principalement destinée aux lecteurs tels que :

• Les ingénieurs qui s’apprêtent à commencer un développement système sérieux avec MySQL
• Les ingénieurs backend / orientés infrastructure qui souhaitent examiner les conceptions de tables existantes
• Les développeurs web et programmeurs qui veulent des « types recommandés » par cas d’utilisation

Nous commencerons par organiser les principaux types de données MySQL sous forme de « liste » catégorisée. Ensuite, nous expliquerons les types clés — numériques, chaînes, date/heure, JSON, ENUM/SET — en couvrant leurs caractéristiques, cas d’utilisation typiques et conseils de sélection. Enfin, nous résumerons les erreurs de conception courantes et comment les éviter, ainsi qu’une FAQ.

Ce n’est pas seulement une « liste de termes ». C’est structuré comme un guide de prise de décision pour que vous ne vous retrouviez pas bloqué lors de la conception de tables dans des projets réels. Dans la section suivante, plongeons dans la façon de penser aux types de données et examinons la liste catégorisée.

2. Qu’est-ce qu’un type de données, et pourquoi « choisir le bon type » est-il important ?

Dans une base de données, un « type de données » est une règle qui définit le type de valeurs qu’une colonne peut stocker.
MySQL fournit de nombreux types de données — entiers, décimales, chaînes, dates, binaires, JSON, et plus encore — vous devez donc choisir de manière appropriée en fonction de votre objectif.

Le rôle des types de données

Un type de données n’est pas seulement une « catégorie de format ». Il joue plusieurs rôles simultanément :

• Restreindre le type de données (numérique vs. chaîne, booléen, etc.)
• Définir la plage autorisée et le nombre de chiffres
• Déterminer la mémoire requise (taille de stockage)
• Influencer les structures d’index et les performances de recherche
• Affecter les conversions implicites et les règles de comparaison (par exemple, la collation des chaînes)

En résumé, les types de données ne sont pas simplement des « conteneurs » — ce sont des choix de conception fondamentaux qui affectent tout le cycle de vie de la gestion des données.

Que se passe-t-il si vous choisissez le mauvais type ?

Si vous sélectionnez le mauvais type de données, des problèmes comme ceux-ci se produisent fréquemment dans le travail réel :

• Gaspillage de stockage

Par exemple, si BIGINT (8 octets) suffit mais que vous utilisez par erreur DECIMAL ou LONGTEXT, vous pourriez consommer beaucoup plus d’espace disque que prévu.

• Requêtes plus lentes

Si vous abusez des recherches LIKE sur de grandes colonnes TEXT, ou si les index gonflent parce que vous avez choisi des types numériques excessivement grands, l’exécution SQL a tendance à ralentir.

• Valeurs incohérentes ou débordement

Vous pourriez stocker des valeurs qui ne rentrent pas dans INT, causant des valeurs négatives inattendues, des arrondis ou d’autres problèmes.

• Changements de table coûteux

Surtout sur de grandes tables, changer les types avec ALTER TABLE peut entraîner :

• De longs temps de verrouillage
• Un impact sur le service
• Un travail de migration de données et d’autres risques.

Catégories clés que vous devriez comprendre dès le départ

Les types de données MySQL sont largement catégorisés comme suit :

• Types numériques (entiers, décimales)
• Types de chaînes
• Types de date et d’heure
• Types binaires
• Type JSON
• Types ENUM / SET
• Types de données spatiales

Chaque catégorie présente des compromis différents — forces/faiblesses, « léger vs. lourd », et « facile vs. difficile à rechercher ». C’est pourquoi vous avez besoin de la sélection optimale du type pour chaque cas d’utilisation.

3. Catégories de types de données MySQL (Liste d’aperçu)

Dans cette section, nous résumerons les types de données disponibles dans MySQL sous forme de liste d’aperçu catégorisée. En pratique, les premières questions que vous voulez confirmer sont « Quels types existent ? » et « Lequel devrais‑je utiliser ? ». Nous allons donc présenter clairement les cas d’utilisation, les caractéristiques clés et les noms de types représentatifs, puis expliquer chaque catégorie plus en détail dans les sections suivantes.

3.1 Types numériques

Les types numériques sont la base de tout traitement numérique, incluant les entiers, décimaux et valeurs à virgule flottante.
Cette catégorie est la plus fréquemment utilisée pour les ID, quantités, prix, drapeaux, et bien d’autres usages.

Types d’entiers

Remarques

• Ajouter UNSIGNED double la plage positive.
• INT est utilisé dans de nombreux cas, mais employer BIGINT de façon désinvolte peut alourdir les index.

Types décimaux / à virgule flottante

Remarques

• Pour les montants, DECIMAL est le seul choix raisonnable. Les types à virgule flottante (FLOAT / DOUBLE) peuvent introduire des erreurs.
• Dans les cas impliquant de nombreux calculs, DOUBLE est parfois choisi pour le compromis vitesse/précision.

Autres types numériques

3.2 Types de date et d’heure

La gestion des dates/horaires est très fréquente dans le développement d’applications.
Selon le but, des facteurs comme le « comportement du fuseau horaire », les « mises à jour automatiques » et la « précision au niveau de la seconde » diffèrent, il est donc important de choisir le bon type.

Remarques

• Si vous voulez gérer automatiquement le « updated at », TIMESTAMP est pratique.
• Pour les « logs » ou « historique » où vous devez stocker des horodatages précis, DATETIME est couramment utilisé.

3.3 Types chaîne / binaire

Noms d’utilisateur, e‑mails, mots de passe, descriptions — les chaînes sont souvent la zone la plus complexe dans la conception de tables.

Chaînes de longueur fixe

Chaînes de longueur variable

Texte volumineux (famille TEXT)

Remarques

• Utilisez TEXT lorsque vous devez stocker des chaînes très longues comme le corps d’articles ou de longues descriptions.
• Soyez prudent avec la recherche et la conception des index.

Données binaires (BINARY / BLOB)

※ En général, les gros fichiers ne sont pas stockés dans la base de données ; une conception courante consiste à les stocker dans un stockage externe.

Types ENUM / SET (Énumérations)

Remarques

• Si vous devez modifier la définition du type plus tard, la maintenance devient lourde.
• Cela peut être efficace pour des candidats statiques à petite échelle.

3.4 Type JSON

• Vous obtenez la flexibilité du NoSQL tout en pouvant utiliser les fonctions spécifiques à JSON.
• Cependant, il n’est pas recommandé d’emballer des données fréquemment recherchées dans du JSON. Si elles peuvent être normalisées, elles devraient être modélisées sous forme de tables structurées.

3.5 Types spatiaux

Ils sont utilisés lorsqu’on travaille avec des données géographiques et de localisation.

Dans les applications web typiques, ils ne sont pas souvent employés, mais ils sont importants pour les applications cartographiques et les intégrations GPS.

4. Comment choisir et utiliser chaque type de données (points de décision clés)

Dans cette section, nous approfondissons les catégories présentées ci‑dessus, en nous concentrant sur « comment choisir dans des scénarios réels ».
Connaître simplement les noms ne suffit pas — sélectionner le type de données le mieux adapté a un impact majeur sur la maintenabilité, les performances et l’évolutivité future.

4.1 Comment choisir les types numériques

Critères de choix des types d’entiers

Lors du choix des types d’entiers, concentrez‑vous sur ces trois points :

1. Comprendre la plage maximale requise

• Petits compteurs → TINYINT
• Quantités de produits / drapeaux → SMALLINT / INT
• ID ou logs à grande échelle → BIGINT

Certains projets sur‑utilisent BIGINT pour les clés primaires, mais cela peut facilement entraîner des index plus volumineux et impacter négativement les performances.

2. Considérer activement UNSIGNED

If you only handle positive values (e.g., numeric IDs, inventory counts)
→ using UNSIGNED doubles the range and may allow you to use a smaller type.

3. Pour les valeurs monétaires ou critiques en précision, utilisez DECIMAL

Pour les valeurs où « les erreurs ne sont pas acceptables », évitez FLOAT/DOUBLE et utilisez toujours DECIMAL.

4.2 Comment choisir les types de date et d’heure

Le type approprié dépend de votre cas d’utilisation.

Différences entre DATETIME et TIMESTAMP

Règles générales pour choisir

• Journaux d’application ou enregistrements d’événements → DATETIME (éviter les effets de conversion de fuseau horaire)
• Lorsque vous souhaitez enregistrer automatiquement les horodatages de mise à jour → TIMESTAMP (comportement pratique de mise à jour automatique)

Où YEAR est utile

• Catégories d’exercice fiscal, années de sortie, années de création, etc. → Gérer de façon compacte (1 octet)

4.3 Comment choisir les types de chaîne

Comment décider entre CHAR et VARCHAR

Quand vous devez utiliser CHAR

• La longueur est toujours constante : codes de préfecture, codes de pays, identifiants à longueur fixe, etc.
• Données nécessitant un accès rapide et mises à jour peu fréquentes

Quand vous devez utiliser VARCHAR

• La longueur varie : noms, adresses e‑mail, titres, etc.
• Le meilleur choix par défaut dans la plupart des situations

Devez‑vous utiliser TEXT ?

Avantages de TEXT

• Prend en charge de grands textes (descriptions, corps d’articles, etc.)

Précautions pour TEXT

• L’indexation est limitée (des index de préfixe sont requis)
• Les performances peuvent se dégrader lorsqu’il est utilisé dans des JOIN ou des clauses WHERE
• La recherche et le tri peuvent être lourds

Recommandation :
Utilisez TEXT pour les « chaînes longues » telles que les corps ou les notes,
et utilisez VARCHAR autant que possible pour tout le reste.

4.4 Comment choisir le type JSON

Le type JSON est très utile, mais vous devez l’utiliser « correctement ».

Quand JSON fonctionne bien

• Paramètres flexibles ou données avec un nombre variable de champs
• Cas d’utilisation de recherche limités, ou lorsque l’application l’étend/analyse
• Stockage de données légères qui ne nécessitent pas de table maître

Quand JSON n’est pas adapté

• Données que vous recherchez fréquemment
• Données utilisées pour des recherches filtrées, agrégations ou JOINs
• Données structurées qui devraient être normalisées

Règle générale :
Les données que vous devez rechercher doivent être normalisées et traitées comme une structure.
N’oubliez pas que JSON est « flexible mais faible pour la recherche ».

4.5 Comment choisir les types ENUM / SET

Quand ENUM est approprié

• Les états sont fixes : par ex., statut (draft / published / archived)
• Un petit ensemble d’options qui change rarement

Précautions pour ENUM

• Ajouter ou modifier des valeurs nécessite ALTER TABLE
• Risque de perdre la cohérence avec les définitions côté application

Quand SET est approprié

• Données de petite échelle nécessitant une sélection multiple (par ex., jours de la semaine disponibles, ou lorsqu’il n’y a que quelques options de tag)

Précautions pour SET

• Les combinaisons de valeurs peuvent devenir complexes
• Gérer des états à valeurs multiples peut devenir difficile

4.6 Comment choisir les types Binary / BLOB

BINARY / VARBINARY

• Jetons, ID, valeurs de hachage, etc.
• Binaire à longueur fixe (par ex., UUIDs de 16 octets)

Cas d’utilisation typiques pour les types BLOB

• Petits fichiers, images miniatures, données chiffrées

Mais note

• Stocker de gros fichiers dans la base de données alourdit les sauvegardes
• La charge de lecture/écriture augmente également → Dans les systèmes réels, le stockage externe + la gestion des chemins est recommandé

5. Pratique : comment utiliser la « Liste de référence des types de données » lors de la conception de tables

Dans cette section, nous expliquerons comment utiliser la liste des types de données MySQL dans un flux de travail pratique lors de la conception de tables.
Plutôt que de simplement mémoriser les types, organiser le « pourquoi vous choisissez ce type » à travers la logique et les étapes conduit à une conception de base de données de meilleure qualité.

5.1 Étape 1 : clarifier le « but » et la « nature » de la colonne

Tout d’abord, définissez clairement ce qui sera stocké dans la colonne.

Checklist

• Est-ce numérique, chaîne, date ou un drapeau ?
• Est-ce de longueur variable ou fixe ?
• Quelle est la valeur maximale ou la longueur maximale ?
• NULL doit-il être autorisé ?
• Est-ce susceptible de croître à l’avenir ?

Si vous procédez avec des hypothèses vagues ici, la sélection de type devient inutilement compliquée plus tard.

5.2 Étape 2 : Estimer la plage et le format requis

Ensuite, estimez les limites supérieure/inférieure, longueur des caractères et précision requise des valeurs que vous stockerez.

Exemple : Colonne ID

• Le nombre maximum d’enregistrements atteindra-t-il des dizaines de millions ? Des centaines de millions ? → Cela vous aide à déterminer si INT est suffisant ou si BIGINT est nécessaire.

Exemple : Nom de produit

• Moyenne de 15–25 caractères, maximum autour de 50 ? → VARCHAR(50) est suffisant. TEXT est inutile.

Exemple : Prix

• La précision est-elle requise ? → Vous devriez sélectionner quelque chose comme DECIMAL(10,2) .

5.3 Étape 3 : Considérer le volume de données et les performances

Le choix des types de données MySQL impacte directement les performances.

Considérations clés

• Types trop grands → consomment du stockage et rendent les index plus lourds
• TEXT / BLOB → dégradent les performances de recherche
• JSON → flexible mais faible pour la recherche
• TIMESTAMP → efficace pour les mises à jour automatiques et les comparaisons

En particulier, les colonnes avec index doivent utiliser le type de données le plus léger possible.

5.4 Étape 4 : Valider les types avec des données d’exemple

Après avoir conçu la table, insérez des dizaines à des centaines de lignes de données de test et vérifiez le comportement.

Ce qu’il faut vérifier

• Y a-t-il des problèmes d’arrondi ou de troncature non intentionnels ?
• VARCHAR est-il suffisant, ou devrait-il s’agir de TEXT ?
• Le tri et la recherche de datetime se comportent-ils comme prévu ?
• Performances de lecture/écriture JSON

Les tests avec des données réalistes réduisent « les erreurs de jugement théoriques ».

5.5 Étape 5 : Considérer l’évolutivité et la maintenabilité

À l’étape finale de la conception de table, vérifiez si les changements futurs seront faciles.

Exemples de changements de type lourds

• ENUM (nécessite ALTER TABLE lors de l’ajout de valeurs)
• TEXT → VARCHAR (l’extension est facile, la réduction est risquée)
• FLOAT → DECIMAL (peut changer la sémantique)

Choisissez les types en jugeant si une expansion future est probable.

5.6 Étape 6 : Exemple CREATE TABLE (échantillon pratique)

Voici un exemple de table reflétant les normes courantes de sélection de types de données dans une application web typique.

CREATE TABLE products (
    id           BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name         VARCHAR(100) NOT NULL,
    price        DECIMAL(10,2) NOT NULL,
    stock        INT UNSIGNED NOT NULL DEFAULT 0,
    status       ENUM('draft', 'published', 'archived') NOT NULL DEFAULT 'draft',
    description  TEXT,
    created_at   DATETIME NOT NULL,
    updated_at   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

Points clés dans cet exemple

• id : Utilise BIGINT UNSIGNED en tenant compte de l’échelle future
• name : Chaîne variable de longueur moyenne → VARCHAR
• price : Valeur monétaire → DECIMAL précis
• stock : Nombre d’inventaire → INT UNSIGNED
• status : Ensemble fixe de valeurs → ENUM
• description : Texte potentiellement long → TEXT
• updated_at : TIMESTAMP auto-mise à jour pratique

Comme indiqué, chaque choix de type doit avoir une justification claire, et être capable d’articuler ce raisonnement est la marque d’un bon design.

6. Erreurs courantes et comment les éviter

Parce que MySQL offre de nombreux types de données, plusieurs erreurs courantes apparaissent fréquemment dans les projets réels.
Cette section met en évidence les pièges typiques et fournit des contre-mesures pratiques.

6.1 Utilisation de types de données excessivement grands

Exemples courants

• Rendre tous les ID BIGINT
• Définir toutes les chaînes à VARCHAR(255)
• Utiliser TEXT pour du contenu non textuel

Problèmes

• Stockage gaspillé
• Index gonflés nuisant aux performances des requêtes
• Bande passante réseau gaspillée (transferts de données plus grands)

Comment éviter

• Estimez les valeurs maximales et minimales à l’avance
• Définissez les longueurs de VARCHAR en fonction des preuves
• N’utilisez TEXT que lorsqu’il est réellement nécessaire

6.2 Utilisation de FLOAT/DOUBLE pour les valeurs décimales (problèmes de précision)

Exemples courants

• Stocker les prix en tant que FLOAT
• Les comparaisons numériques échouent à cause des erreurs d’arrondi

Comment éviter

• Utilisez DECIMAL pour l’argent et les valeurs critiques en précision
• Évitez FLOAT / DOUBLE sauf pour des calculs scientifiques ou temporaires

6.3 Colonnes VARCHAR surdimensionnées

Exemples courants

• Utiliser VARCHAR(255) par défaut
• Définir des longueurs importantes pour des colonnes qui ne stockent qu’environ 30 caractères

Problèmes

• Mémoire et stockage gaspillés
• Les index deviennent souvent plus lourds

Comment éviter

• Estimez les longueurs moyennes et maximales à partir des données réelles
• Évitez les tailles inutilement grandes (par ex., adresses e‑mail → VARCHAR(100) )

6.4 Surutilisation des types TEXT

Exemples courants

• Supposer que “string = TEXT”
• Utiliser TEXT pour des données qui nécessitent un filtrage ou une recherche

Problèmes

• De nombreuses limitations d’indexation
• Recherches LIKE lourdes
• Traitement plus lent dans les JOINs

Comment éviter

• Utilisez TEXT uniquement pour du contenu long tel que des descriptions ou des corps de texte
• Stockez les chaînes recherchables dans VARCHAR chaque fois que possible

6.5 Choisir les types Date/Heure sans comprendre leurs propriétés

Exemples courants

• Utiliser DATETIME pour tout
• Utiliser DATETIME pour “updated at”, ce qui ne se met pas à jour automatiquement
• Les horodatages changent à cause des différences de fuseau horaire

Comment éviter

• Besoin de mise à jour automatique : TIMESTAMP
• Souhait d’éviter les décalages de fuseau horaire : DATETIME
• Besoin uniquement de l’année : YEAR

6.6 Utilisation trop détendue d’ENUM / SET

Exemples courants

• Utiliser ENUM même si les options peuvent changer à l’avenir
• Utiliser SET comme une liste séparée par des virgules

Problèmes

• Les changements nécessitent ALTER TABLE
• L’incohérence avec les définitions côté application est plus probable

Comment éviter

• Si les valeurs peuvent augmenter, gérez‑les dans une table maître séparée
• Utilisez ENUM uniquement lorsque l’ensemble est petit et réellement fixe

6.7 Encombrer trop de données dans JSON « parce que c’est pratique »

Exemples courants

• Envelopper des structures qui devraient être normalisées dans JSON
• Stocker des données fréquemment recherchées dans JSON

Problèmes

• Les performances de recherche se dégradent
• Les index sont moins efficaces / plus difficiles à utiliser
• Plus de travail de parsing côté application
• Le design sans schéma rend la cohérence plus facile à rompre

Comment éviter

• Utilisez JSON uniquement pour les données que vous ne recherchez pas
• Limitez‑le à des “données petites et variables” comme les paramètres
• Normalisez les informations utilisées pour les JOINs et la recherche

6.8 Sous‑estimer le coût des changements de type

Problèmes

• ALTER TABLE peut être extrêmement lourd sur de grandes tables
• Des temps d’arrêt du service ou de longs verrous peuvent survenir
• Dans certains cas, une migration de données est requise

Comment éviter

• Planifiez la croissance future dès la phase de conception
• Utilisez ENUM avec précaution
• Laissez de la marge dans la précision/échelle de DECIMAL (mais n’exagérez pas)

7. Résumé

MySQL offre une grande variété de types de données, et le type que vous choisissez peut affecter de manière significative les performances, l’évolutivité et la maintenabilité.
En particulier dans des environnements comme les applications web où les données ont tendance à croître, les décisions de conception précoces influencent directement la qualité à long terme.

Points clés de cet article

• Les types de données sont des facteurs critiques qui affectent le « type de valeur, la portée, la précision, le stockage et les performances ».
• Les types numériques, chaînes, date/heure, JSON, ENUM/SET et BLOB ont chacun leurs forces et leurs faiblesses.
• Les entiers, les chaînes et les types date/heure sont les plus utilisés, il est donc important de bien les choisir.
• JSON et ENUM sont pratiques, mais une mauvaise utilisation peut rendre la maintenance difficile.
• Surutiliser TEXT et BLOB peut dégrader les performances.
• Une approche de conception rationnelle est : « Objectif → Portée → Performances → Évolutivité ».

Une checklist de conception que vous pouvez utiliser dès aujourd’hui

• L’objectif de la colonne est-il clairement défini ?
• Comprenez-vous les valeurs maximales et minimales possibles ?
• Existe-t-il des preuves justifiant la longueur VARCHAR choisie ?
• Utilisez-vous DECIMAL pour l’argent ?
• Les horodatages « updated at » sont-ils gérés avec TIMESTAMP et mis à jour automatiquement le cas échéant ?
• Avant d’utiliser ENUM, avez‑vous envisagé que les valeurs puissent augmenter à l’avenir ?
• Évitez‑vous les conceptions où la recherche devient lente à cause d’une surutilisation du JSON ?
• Avez‑vous conçu pour éviter les opérations lourdes ALTER TABLE sur de grands ensembles de données ?

Enfin

Il n’existe pas toujours une réponse unique « correcte » pour choisir les types de données MySQL.
Cependant, si vous choisissez avec un objectif et la croissance future en tête, vous pouvez prévenir les problèmes majeurs et garder votre structure de données propre.

En fin de compte, le meilleur choix dépend de la nature de votre projet, du volume de données et des exigences de l’application. Mais si vous utilisez les critères présentés dans cet article comme base, vous devriez pouvoir faire de meilleurs choix de types de données dans n’importe quelle situation.

Ensuite, nous introduirons une section FAQ qui résume les questions fréquemment posées dans le travail réel.
Lorsque vous n’êtes pas sûr du choix du type, consulter cette FAQ en premier vous aidera à décider plus facilement.

8. FAQ

Choisir les types de données MySQL est un domaine où les décisions peuvent varier considérablement selon l’expérience du monde réel. Ici, nous compilons les questions courantes des équipes de développement et fournissons des réponses courtes et claires.

Q1. Dois‑je utiliser INT ou BIGINT ?

R : Utilisez INT par défaut. Utilisez BIGINT uniquement s’il peut dépasser 2,1 milliard à l’avenir.

INT (4 octets) supporte jusqu’à environ 2,1 milliard et suffit pour la plupart des applications. Envisagez BIGINT pour les journaux, les services à fort trafic ou les systèmes qui peuvent générer un nombre extrêmement élevé d’ID.

Q2. Dois‑je utiliser VARCHAR ou TEXT ?

R : Utilisez VARCHAR si vous avez besoin de recherche. Utilisez TEXT pour du contenu long.

• VARCHAR : Favorise les index et est meilleur pour les recherches
• TEXT : Bon pour le contenu long mais pas idéal pour la recherche ou les JOINs

※ Une surutilisation de TEXT peut entraîner une dégradation des performances.

Q3. Est‑il acceptable de stocker de l’argent en DOUBLE ?

R : Non. Utilisez toujours DECIMAL.

DOUBLE et FLOAT peuvent introduire des erreurs d’arrondi, ils ne sont donc pas adaptés à l’argent ou aux valeurs nécessitant une précision élevée. Dans les systèmes d’entreprise, DECIMAL(10,2) ou DECIMAL(12,2) est une norme courante.

Q4. Je ne comprends pas la différence entre DATETIME et TIMESTAMP. Comment choisir ?

R : Utilisez TIMESTAMP si vous avez besoin de mises à jour automatiques. Utilisez DATETIME si vous devez stocker un horodatage précis sans conversion de fuseau horaire.

• TIMESTAMP : Mise à jour automatique et conversion de fuseau horaire
• DATETIME : Non affecté par les fuseaux horaires ; stocke la date/heure « tel quel »

DATETIME est souvent utilisé pour les journaux et les tables d’historique.

Q5. Est‑il sûr d’utiliser ENUM ?

R : C’est utile uniquement lorsque les valeurs sont « garanties de ne pas changer ».

ENUM est léger et pratique, mais ajouter ou modifier des valeurs nécessite ALTER TABLE. Pour les champs susceptibles d’évoluer, une gestion maître dans une table séparée est recommandée.

Q6. Puis‑je simplement utiliser JSON pour l’instant ?

R : Utilisez JSON uniquement pour les données que vous ne recherchez pas. Les données que vous recherchez doivent être normalisées.

JSON est flexible, mais il présente des faiblesses de performance.

• Faible pour la recherche
• Les structures d’index deviennent plus complexes
• Plus difficile de maintenir la cohérence des données

Il fonctionne bien pour les paramètres et les options — des attributs qui ne sont pas utilisés comme critères de recherche.

Q7. Comment devrais‑je déterminer la longueur maximale pour VARCHAR ?

R : Estimez le maximum à partir de données réelles et ajoutez une petite marge.

Exemple : Adresse e‑mail → VARCHAR(100) suffit
Exemple : Nom d’utilisateur → VARCHAR(50) convient souvent

« 255 juste parce que » n’est pas recommandé.

Q8. Si j’ai choisi le mauvais type, puis‑je le changer plus tard ?

R : Oui, mais cela peut être très lourd sur les grandes tables.

ALTER TABLE implique souvent des scans complets et des reconstructions, ce qui peut entraîner des temps d’arrêt ou de longs verrous.

→ Une planification minutieuse à l’étape de conception initiale est la plus importante