Type d'ENUM MySQL et tables de jonction

Question

Mon exigence

Une table doit maintenir un estado colonne.

Cette colonne représente l'un des 5 états.

conception initiale

Je me suis dit que je pouvais simplement en faire une colonne entière et représenter les états par une valeur numérique.

• 0 = démarrage
• 1 = en cours d'exécution
• 2 = accidenté
• 3 = en pause
• 4 = arrêté

Comme je ne veux pas que mon application maintienne le mappage des entiers vers leur description sous forme de chaîne, je prévois de les placer dans une table de description d'état séparée (en m'appuyant sur une relation FK).

J'ai ensuite découvert que MySQL dispose d'un type ENUM qui correspond exactement à mes besoins. Outre une dépendance directe à MySQL, l'utilisation du type ENUM présente-t-elle des inconvénients ?

Answer 1

• La modification de l'ensemble des valeurs d'un ENUM nécessite une modification de l'ensemble des valeurs. ALTER TABLE ce qui pourrait entraîner une restructuration de la table - une opération incroyablement coûteuse (la restructuration de la table ne se produit pas si vous ajoutez simplement une nouvelle valeur à la fin de la définition ENUM, mais si vous en supprimez une, ou si vous changez l'ordre, il y a une restructuration de la table). Alors que la modification de l'ensemble des valeurs dans une table de consultation est aussi simple qu'un INSERT ou un DELETE.

• Il n'y a aucun moyen d'associer d'autres attributs aux valeurs d'un ENUM, comme ceux qui sont retirés, et ceux qui peuvent être placés dans une liste déroulante dans votre interface utilisateur. Cependant, une table de consultation peut inclure des colonnes supplémentaires pour de tels attributs.

• Il est très difficile d'interroger un ENUM pour obtenir une liste de valeurs distinctes, ce qui nécessite essentiellement d'interroger la définition du type de données à partir de INFORMATION_SCHEMA et d'analyser la liste à partir du BLOB retourné. Vous pouvez essayer SELECT DISTINCT status de votre table, mais cela ne permet d'obtenir que les valeurs d'état actuellement utilisées, qui peuvent ne pas être toutes les valeurs de l'ENUM. Cependant, si vous conservez les valeurs dans une table de consultation, il est facile de les interroger, de les trier, etc.

Je ne suis pas un grand fan de l'ENUM, comme vous pouvez le voir. :-)

Il en va de même pour les contraintes CHECK qui comparent simplement une colonne à un ensemble fixe de valeurs. Bien que MySQL ne supporte pas les contraintes CHECK de toute façon.

Mise à jour : MySQL 8.0.16 implémente maintenant Contraintes de CHECK .

Answer 2

Voici un article sur comparaison de la vitesse de l'enum . Il donne peut-être quelques indications. IMHO il devrait être limité à une utilisation dans une liste fixe de chaînes ("Oui/Non", "Enfant/Adulte") qui avec une probabilité de 99% ne change pas dans le futur.

Answer 3

Les Enums dans MySQL sont mauvais pour les raisons déjà expliquées.
Je peux ajouter le fait suivant : l'enum n'assure aucune sorte de validation du côté du serveur. Si vous insérez une ligne avec une valeur qui n'existe pas dans la définition de l'enum, vous obtiendrez une belle réponse de type <empty> o NULL dans la base de données, en fonction de la possibilité d'utiliser la valeur NULL de la déclaration du champ enum.

Ce que je veux dire à propos de tinyints :

• les enums sont limités à 65535 valeurs
• si vous n'avez pas besoin de plus de 256 valeurs, tinyint prendra moins d'espace pour chaque ligne, et son comportement est beaucoup plus "prévisible".

Answer 4

Si vous avez beaucoup de données dans votre base de données (plus de données que vous n'avez de RAM) et que vos valeurs ENUM ne changeront JAMAIS, je choisirais ENUM plutôt que la jointure. Cela devrait être plus rapide.
Pensez-y, dans le cas de la jointure, vous avez besoin d'un index sur votre clé étrangère et d'un index sur votre clé primaire dans l'autre table. Comme Riho l'a dit, voyez les benchmarks.

Answer 5

Un tableau serait plus facile à internationaliser. Mais il en va de même pour une classe située entièrement en dehors de la base de données. Ce type de contrôle peut être difficile à déboguer lorsqu'il ne fait pas partie de la logique de l'entreprise, et ne relève généralement pas de la responsabilité des personnes chargées de la base de données.

En tant qu'optimisation, c'est probablement très prématuré ; mais le PO le propose principalement comme une fonctionnalité pratique de toute façon.

Voir aussi http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/