Avertissement
SET et ENUM sont des types propres à MySQL. Ils sont donc à utiliser avec une grande prudence !
Pourquoi avoir inventé ces types propres à MySQL ?
La plupart des SGBD implémentent ce qu'on appelle des contraintes d'assertions, qui permettent de définir les valeurs que
peuvent prendre une colonne (par exemple, on pourrait définir une contrainte pour une colonne contenant un âge, devant être
compris entre 0 et 130).
MySQL n'implémente pas ce type de contrainte et a par conséquent créé deux types de données spécifiques (SET et ENUM),
pour pallier en partie ce manque.
Dans quelles situations faut-il utiliser ENUM ou SET ?
La meilleure réponse à cette question est : jamais ! Je déconseille fortement l'utilisation des SET et des ENUM. Je vous ai
présenté ces deux types par souci d'exhaustivité, mais il faut toujours éviter autant que possible les fonctionnalités propres à un
seul SGBD. Ceci afin d'éviter les problèmes si un jour vous voulez en utiliser un autre.
Mais ce n'est pas la seule raison. Imaginez que vous vouliez utiliser un ENUM ou un SET pour un système de catégories. Vous
avez donc des éléments qui peuvent appartenir à une catégorie (dans ce cas, vous utilisez une colonne ENUM pour la catégorie)
ou appartenir à plusieurs catégories (et vous utilisez SET).
Code : SQL
categorie ENUM("Soupes", "Viandes", "Tarte", "Dessert")
categorie SET("Soupes", "Viandes", "Tarte", "Dessert")
Tout se passe plutôt bien tant que vos éléments appartiennent aux catégories que vous avez définies au départ. Et puis tout à
coup, vous vous retrouvez avec un élément qui ne correspond à aucune de vos catégories, mais qui devrait plutôt se trouver
dans la catégorie "Entrées". Avec SET ou ENUM, il vous faut modifier la colonne categorie pour ajouter "Entrées" aux valeurs
possibles. Or, une des règles de base à respecter lorsque l'on conçoit une base de données, est que la structure de la base (donc
les tables, les colonnes) ne doit pas changer lorsque l'on ajoute des données. Par conséquent, tout ce qui est susceptible de
changer doit être une donnée, et non faire partie de la structure de la base.
Il existe deux solutions pour éviter les ENUM, et une solution pour éviter les SET.
Pour éviter ENUM
Vous pouvez faire de la colonne categorie une simple colonne VARCHAR(100). Le désavantage est que vous ne
pouvez pas limiter les valeurs entrées dans cette colonne. Cette vérification pourra éventuellement se faire à un autre
niveau (par exemple au niveau du PHP si vous faites un site web avec PHP et MySQL).
Vous pouvez aussi ajouter une table Categorie qui reprendra toutes les catégories possibles. Dans la table des éléments,
il suffira alors de stocker une référence vers la catégorie de l'élément.
Pour éviter SET
La solution consiste en la création de deux tables : une table Categorie, qui reprend les catégories possibles, et une table qui lie
les éléments aux catégories auxquels ils appartiennent.
Types temporels
Pour les données temporelles, MySQL dispose de cinq types qui permettent, lorsqu'ils sont bien utilisés, de faire énormément de
choses.
Avant d'entrer dans le vif du sujet, une petite remarque importante : lorsque vous stockez une date dans MySQL, certaines
vérifications sont faites sur la validité de la date entrée. Cependant, ce sont des vérifications de base : le jour doit être compris
entre 1 et 31 et le mois entre 1 et 12. Il vous est tout à fait possible d'entrer une date telle que le 31 février 2011. Soyez donc
prudents avec les dates que vous entrez et récupérez.
Les cinq types temporels de MySQL sont DATE, DATETIME, TIME, TIMESTAMP et YEAR.
Partie 1 : MySQL et les bases du langage SQL
31/414
www.openclassrooms.com
SET et ENUM sont des types propres à MySQL. Ils sont donc à utiliser avec une grande prudence !
Pourquoi avoir inventé ces types propres à MySQL ?
La plupart des SGBD implémentent ce qu'on appelle des contraintes d'assertions, qui permettent de définir les valeurs que
peuvent prendre une colonne (par exemple, on pourrait définir une contrainte pour une colonne contenant un âge, devant être
compris entre 0 et 130).
MySQL n'implémente pas ce type de contrainte et a par conséquent créé deux types de données spécifiques (SET et ENUM),
pour pallier en partie ce manque.
Dans quelles situations faut-il utiliser ENUM ou SET ?
La meilleure réponse à cette question est : jamais ! Je déconseille fortement l'utilisation des SET et des ENUM. Je vous ai
présenté ces deux types par souci d'exhaustivité, mais il faut toujours éviter autant que possible les fonctionnalités propres à un
seul SGBD. Ceci afin d'éviter les problèmes si un jour vous voulez en utiliser un autre.
Mais ce n'est pas la seule raison. Imaginez que vous vouliez utiliser un ENUM ou un SET pour un système de catégories. Vous
avez donc des éléments qui peuvent appartenir à une catégorie (dans ce cas, vous utilisez une colonne ENUM pour la catégorie)
ou appartenir à plusieurs catégories (et vous utilisez SET).
Code : SQL
categorie ENUM("Soupes", "Viandes", "Tarte", "Dessert")
categorie SET("Soupes", "Viandes", "Tarte", "Dessert")
Tout se passe plutôt bien tant que vos éléments appartiennent aux catégories que vous avez définies au départ. Et puis tout à
coup, vous vous retrouvez avec un élément qui ne correspond à aucune de vos catégories, mais qui devrait plutôt se trouver
dans la catégorie "Entrées". Avec SET ou ENUM, il vous faut modifier la colonne categorie pour ajouter "Entrées" aux valeurs
possibles. Or, une des règles de base à respecter lorsque l'on conçoit une base de données, est que la structure de la base (donc
les tables, les colonnes) ne doit pas changer lorsque l'on ajoute des données. Par conséquent, tout ce qui est susceptible de
changer doit être une donnée, et non faire partie de la structure de la base.
Il existe deux solutions pour éviter les ENUM, et une solution pour éviter les SET.
Pour éviter ENUM
Vous pouvez faire de la colonne categorie une simple colonne VARCHAR(100). Le désavantage est que vous ne
pouvez pas limiter les valeurs entrées dans cette colonne. Cette vérification pourra éventuellement se faire à un autre
niveau (par exemple au niveau du PHP si vous faites un site web avec PHP et MySQL).
Vous pouvez aussi ajouter une table Categorie qui reprendra toutes les catégories possibles. Dans la table des éléments,
il suffira alors de stocker une référence vers la catégorie de l'élément.
Pour éviter SET
La solution consiste en la création de deux tables : une table Categorie, qui reprend les catégories possibles, et une table qui lie
les éléments aux catégories auxquels ils appartiennent.
Types temporels
Pour les données temporelles, MySQL dispose de cinq types qui permettent, lorsqu'ils sont bien utilisés, de faire énormément de
choses.
Avant d'entrer dans le vif du sujet, une petite remarque importante : lorsque vous stockez une date dans MySQL, certaines
vérifications sont faites sur la validité de la date entrée. Cependant, ce sont des vérifications de base : le jour doit être compris
entre 1 et 31 et le mois entre 1 et 12. Il vous est tout à fait possible d'entrer une date telle que le 31 février 2011. Soyez donc
prudents avec les dates que vous entrez et récupérez.
Les cinq types temporels de MySQL sont DATE, DATETIME, TIME, TIMESTAMP et YEAR.
Partie 1 : MySQL et les bases du langage SQL
31/414
www.openclassrooms.com