Section courante

A propos

Section administrative du site

Les raisons pour lesquelles le type de données «ENUM» MySQL est une mauvaise pratique

Beaucoup de discussion existe sur le forum de l'Internet concernant les bonnes et les mauvaises pratiques avec la base de données MySQL. L'un de celle-ci concerne les discussions de type de données «ENUM». Ce type de données s'inspire grandement des langages de programmation évolués et s'est vu introduit dans la base de données sans pour autant analyser toutes les conséquences de cet acte. Ce type de données se révèle avoir plus d'inconvénients que d'avantage lorsqu'il est inclus dans des grands systèmes. Voici donc la liste des points négatifs répertoriés par de nombreux forums :

1 - Coût d'entretien peut-être très cher

Bien que l'humain a une certaine difficulté a estimé les futurs besoins de Recherche & Développement, l'entretient d'une énumération oblige nécessaire du faire du développement dès que l'on ajoute une nouvelle valeur dans l'énumération.

2 - Les données d'une énumération ne sont pas traitées comme des données

Chacun des valeurs que vous indiquez dans l'énumération est une donnée mobile, donc elle n'appartient pas réellement à la base de données. Ainsi, on entrepose des éléments de données dans un endroit étant censé contenir uniquement les informations cruciales du modèle de données. De ce fait, on viole une des règles de forme normale de base de données.

3 - Il n'est pas possible d'étendre les informations associées à l'énumération

Si vous utilisez un identificateur, vous pouvez avoir une association vers une autre table afin d'obtenir les informations supplémentaires associées avec votre élément, tandis que l'énumération n'a pas d'association pouvant s'étendre vers une autre table. Il n'est pas possible d'avoir une énumération partagée entre deux tables comme on le fait dans un langage de programmation comme le C ou le Pascal.

4 - Sélection d'un élément d'énumération à partir d'une application

Si vous devez faire choisir à votre utilisé les différentes valeurs que suggère votre énumération directement dans l'application, il n'est pas simple de voir avoir la liste des énumérations d'un champ d'une table. Vous ne pouvez pas tout simplement faire une requête SQL comme ceci : «SELECT DISTINCT champ FROM table ORDER BY champ;»

5 - C'est une technique d'optimisation douteuse

L'un des 2 points de l'optimisation, soulève le fait qu'en éliminant la référence vers une table externe, on accélère grandement le traitement, en évitant un goulot d'étranglement. C'est aspect était vrai avec dBase III, lequel avait une table par fichier, mais si vous n'utilisez par type de table MyISAM, vous ne constaterez pas d'effet néfaste notable. Le second point, c'est qu'en réduisant le nombre de tables et les clefs étrangères, on allège le système et il est donc plus rapide.

6 - Les colonnes ENUM ont un comportement différent

Supposons que vous souhaitez insérer une valeur n'étant pas dans la liste d'énumération et que vous n'êtes pas en mode «STRICT» de MySQL, il insèrera une chaine de caractères vide et vous aurez donc perdu votre référence d'énumération. Ce comportement est logique et conforme au attend, mais risque de provoquer de nombreux bogues de programmation et une certaine difficulté à maintenir le système.

7 - Portabilité SGBD limité

Si vous souhaitez transférer vos données de MySQL vers une base de données d'un format différent autre que PostgreSQL et MariaDB, il ne sera pas nécessairement supporté et vous aurez donc un traitement supplémentaire à faire pour transférer vos données.

Conclusion

En conclusion, à l'exception de la situation d'une relation universelle (une table de relation pour toutes les tables, laquelle nécessite des valeurs de source et de destination bien précise), il ne semble pas y avoir d'exemple concret de l'utilité de ce type de données. Si vous envisagez d'utiliser malgré tout ce type de données, vous serez donc confronté une situation d'exception ne s'appliquant pas normalement, et de ce fait aurez donc à débattre et justifier continuellement de la bienséance de ce type de données dans votre système. De plus, utiliser le mode «STRICT» pour le développement avec ce type de données, vous aurez moins de surprises.

Voir également

Langage de programmation - MySQL - Type de données élémentaires

Dernière mise à jour : Mercredi, le 19 octobre 2016