Bonjour à tous!
Imaginons que je veuille gérer le profil d un utilisateur avec sa couleur de cheveux qu il choisit depuis une liste déroulante.
Sous MySQL, vaut-il mieux créer une table pour les couleurs de cheveux et construire la liste déroulante à partir de cette table
 
OU
 
Utiliser le type ENUM et récupérer les valeurs possibles par une "rétro-ingénieurie" sur la table? Est-ce possible en SQL?
 
Quels les les pour et les contre de chacunes des solutions?

Personnelement, je me poserai les questions : existe-t-il beaucoup de couleur de cheveux ? Seront-elles amenés à changer ?
 
Non et non, donc à priori je vois pas l'intéret d'utiliser une deuxième table. Ca te fera une requête en plus ou des requetes avec jointure.
 
Enfin bon, il y'a surement ici des gens plus expérimentés que moi, mais je donne mon avis  

Oui, les couleurs de cheveux n'étaient qu'un exemple!
Donc à priori ENUM pour les attributs simples et changeant peu ou pas et deuxième table pour des attributs pouvant changer (et possédant éventuellement plsusieurs infos ne pouvant pas être mises dans un ENUM)?

Perso, je suis contre.
 
Les valeurs d'un ENUM n'étant pas sélectionnables, ça t'oblige dans ton code de haut niveau d'avoir aussi la liste des éléments.
Ca t'oblige donc à maintenir autant de liste que tu as d'applications qui viennent utiliser la base. Aujourd'hui, une seule, et demain ? Dans 10 ans, ne va-t-on pas vouloir avoir plus de précision sur tes valeurs ? Genre, y'a châtin clair, châtin foncé, auburn, blond cendré, etc. Ce jour, c'est une galère à modifier.
 
Bref. Pour moi, la question ne se pose même pas : ENUM ne doit pas servir pour remplir la valeur d'un attribut.
Qu'il serve à traduire en langage humain des éléments immutables, à la limite (oui/non, statut d'une commande -et encore-, etc.). Pour le reste, c'est une économie de chandelle pour ce qui est du dev, qui peut se transformer en cauchemar par la suite.

Mais le fait d'avoir à faire des jointures pour la moindre liste n'est-il pas aussi couteux côté SGBD?
Parce que si je veux gérer la couleur de cheveux, la taille, les yeux, le poids, la caractère et j'en passe... il va falloir faire des jointures de partout!

Non, si tu fais des jointures sur des tables, de structure simple, et avec peu de lignes qui plus est, ça n'impact pour ainsi dire pas du tout les performances.

comment ca les valeurs ne sont pas sélectionnables ?  
 
on peut tout a fait recuperer les valeurs d'un champ enum avec un show column  
 
dans le cas  d'un champ enum, mysql stocke une table de correspondance entre la valeur du champ ( blond , chatain , .. ) et un entier  
 
quand il fait la recherche , il ne compare donc qu'une seul fois la valeur recherchée avec les différentes valeurs du champ enum, ensuite , ce sont des comparaisons d'entier  
 
c'est donc sensiblement plus rapide  
 
en plus , le code et la structure de la table sont plus lisibles
 
par contre, je le deconseille pour des valeur pouvant etre modifiée regulierement ( j'aime pas trop laisser les gens faire des ALTER TABLE  )