Table vs Enum

Version imprimable

15/04/2018, 18h14
Firlfire

Table vs Enum

Bonjour!

Dans certaines applis on a besoin qu'un utilisateur choisisse une/des valeur(s) (select & multiselect). Jusqu'à maintenant j'ai toujours créé une table qui contenait ces valeurs, par exemple:
Competition:
- idCompetition (pk)
- type (fk on typeCompetition.idTypeCompetition )

typeCompetition
- idTypeCompetition (pk)
- nom (varchar)

Ici le select est remplie avec les données de la table typeCompetition

J'ai découvert il y a peu qu'il existe des Enum qui définissent les valeurs possibles pour un champ.
Je voudrais donc savoir quelle est le meilleure méthode ? Que se soit pour le stockage et la récupération.
Est-ce qu'on peut requêter sur une Enum ? Que se soit pour remplir un select html ou comme condition dans une requête (WHERE column=EnumValue, GROUP BY EnumValues, ...)

Merci à vous !
16/04/2018, 10h42
Artemus24

Salut Firlfire.

Citation:

Envoyé par Firlfire

Je voudrais donc savoir quelle est le meilleure méthode ? Que se soit pour le stockage et la récupération.

Il n'y a pas de meilleure méthode, il y a juste des cas particuliers.

Si vous définnissez la colonne sexe, vous aurez que deux valeurs possibles, à savoir H(omme et F(emme.
Vous pouvez utiliser un enum car sa forme abrégé est parlante 'H' et 'F' et ne va pas évoluer au cours du temps.

Son avantage est dans sa forme compacte et utiliser peut de volumétrie. Je vous conseille de lire le lien ci-après :
--> https://dev.mysql.com/doc/refman/5.7/en/enum.html

Dans les autres cas, le mieux est d'utiliser la déclarative basée sur les clef étrangères.

@+
16/04/2018, 20h17
escartefigue

Bonjour,

Le choix de la solution dépend de la stabilité du domaine de valeur (de la liste des valeurs possibles si vous préférez)

Si celui-ci est très stable, alors une contrainte "check" est la solution la plus simple
L'intérêt du choix d'un type Enum est l'encombrement, pour l'exemple du code sexe peu d'intérêt comparativement à un char(1) avec contrainte check : indexer une colonne qui ne peut prendre que 2 (voire 4 valeurs si on ajoute "indéterminé" et "inconnu") ne sert à rien en terme de recherches (hors accès séquentiel sur index couvrant donc); et du char(1) est par définition très peu encombrant :P
Si au contraire le contenu change fréquemment, une table avec une date de début et de fin de validité, est la bonne solution

Salut à tous.

Citation:

Envoyé par Escartefigue

pour l'exemple du code sexe peu d'intérêt comparativement à un char(1) avec contrainte check : indexer une colonne qui ne peut prendre que 2

Votre proposition serait fort intéressante à la condition que la contrainte check fonctionne sous MySql, or ce n'est pas le cas.
Mais on peut gérer cela en passant par une view avec l'option check. Voir mon exemple ci-après :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE `base`
        DEFAULT CHARACTER SET `latin1`
        DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `test`
--------------
 
--------------
create table `test`
( `id`    integer  unsigned NOT NULL auto_increment primary key,
  `sexe`  char(01) NOT NULL,
  check (sexe IN ('H','F'))
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
insert into `test` (`sexe`) values ('H')
--------------
 
--------------
insert into `test` (`sexe`) values ('F')
--------------
 
--------------
insert into `test` (`sexe`) values ('Z')
--------------
 
--------------
select * from test
--------------
 
+----+------+
| id | sexe |
+----+------+
|  1 | H    |
|  2 | F    |
|  3 | Z    |
+----+------+
--------------
drop view if exists `vue`
--------------
 
--------------
create view `vue` as
  select  id, sexe
    from  `test`
   where  sexe in ('H','F')
    with  check option
--------------
 
--------------
insert into `vue` (`sexe`) values ('H')
--------------
 
--------------
insert into `vue` (`sexe`) values ('F')
--------------
 
--------------
insert into `vue` (`sexe`) values ('Z')
--------------
 
ERROR 1369 (HY000) at line 62: CHECK OPTION failed 'base.vue'
--------------
select * from vue
--------------
 
+----+------+
| id | sexe |
+----+------+
|  1 | H    |
|  2 | F    |
|  4 | H    |
|  5 | F    |
+----+------+
--------------
select * from test
--------------
 
+----+------+
| id | sexe |
+----+------+
|  1 | H    |
|  2 | F    |
|  3 | Z    |
|  4 | H    |
|  5 | F    |
+----+------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
Appuyez sur une touche pour continuer...

Citation:

Envoyé par Escartefigue

(voire 4 valeurs si on ajoute "indéterminé" et "inconnu") ne sert à rien en terme de recherches (hors accès séquentiel sur index couvrant donc); et du char(1) est par définition très peu encombrant

En effet, mettre un index sur la colonne sexe n'a aucun intérêt, parce que le nombre de valeurs est trop petit.

Les enum n'ont aucun intérêt, à cause du problème d'intégrité dû à check qui ne fonctionne pas sous MySql.

@+

17/04/2018, 12h34
escartefigue

Citation:

Envoyé par Artemus24

Votre proposition serait fort intéressante à la condition que la contrainte check fonctionne sous MySql, or ce n'est pas le cas.

Exact, mea-culpa. D'ailleurs étonnant ce manque :weird: et pourquoi ne pas l'avoir corrigé dans la V8... mystère
18/04/2018, 12h14
Firlfire

Merci à tous pour vos réponses utiles et instructives ! :)