29-10-2017, 11:31 AM
Pour info, l'ENUM revient à faire ta dernière colonne: les valeurs sont, en pratique, stockées dans un entier et converties à la volée par MySQL en la chaîne de caractères correspondante ("Compact data storage in situations where a column has a limited set of possible values. The strings you specify as input values are automatically encoded as numbers" https://dev.mysql.com/doc/refman/5.7/en/enum.html ). Ca a l'avantage aussi de ne pas requérir une connaissance magique côté client de "1 = Militaire, 2 = Commercial, etc" et d'être très lisible (on voit "MILITAIRE" comme valeur de colonne au lieu de juste "1").
Autre avantage: cela t'évites de stocker, par mégarde, un nombre qui ne correspond à aucun cursus (alors qu'un type TINYINT UNSIGNED permettra de stocker n'importe quoi entre 0 et 255, y compris des valeurs qui n'ont pas de sens). Cela peut t'éviter, par exemple, de foirer la validation des entrées du serveur PHP. Typiquement, si ta page web de choix de cursus a un <select><option value="1">Militaire</option><option value="2">Commercial... alors avec un stockage INT en BDD, tu te retrouves obligé de valider que le choix est 1, 2, 3 ou 4 (disons qu'il n'y a que 4 cursus, je n'ai plus le nombre en tête) dans ton code PHP, *avant* de l'envoyer à la BDD (sinon, la BDD contiendra des données incohérente, genre le cursus 42).
Avec un ENUM, tu peux laisser la BDD faire cette vérification (pour peu que les paramètres STRICT soient bien établis). Ta page devient <select><option value="MILITAIRE">Militaire</option><option value="COMMERCIAL">Commercial... et ton serveur PHP n'a (éventuellement) même plus besoin de valider l'entrée de l'utilisateur (ou juste leur existence): le code PHP passe la valeur entrée par l'utilisateur direct à la BDD, et si la BDD ne trouve pas cette valeur dans l'ENUM, alors elle lancera toute seule une exception (SIGNAL) que le code PHP catchera (si PDO est utilisé, c'est quasi-natif) et la valeur sera refusée à l'enregistrement. Perso, c'est ce que je fais sur Iamanoc (que j'ai un peu délaissé ces derniers mois :/ ): cela permet de faire moins de code et de le faire de manière plus sûre (on ne peut pas oublier un check ou une valeur de l'ENUM quand c'est la BDD qui fait directement les vérifications).
Note que, pour l'info, si plusieurs cursus pouvaient se faire en parallèle, "SET" aurait fonctionné tout pareil que ENUM (à la différence que SET permet de stocker plusieurs "valeurs" d'un ENUM en même temps, genre "MILITAIRE, COMMERCIAL" au lieu de juste l'un ou juste l'autre, cf https://dev.mysql.com/doc/refman/5.7/en/set.html )
Bonne création de jeu à toi
Autre avantage: cela t'évites de stocker, par mégarde, un nombre qui ne correspond à aucun cursus (alors qu'un type TINYINT UNSIGNED permettra de stocker n'importe quoi entre 0 et 255, y compris des valeurs qui n'ont pas de sens). Cela peut t'éviter, par exemple, de foirer la validation des entrées du serveur PHP. Typiquement, si ta page web de choix de cursus a un <select><option value="1">Militaire</option><option value="2">Commercial... alors avec un stockage INT en BDD, tu te retrouves obligé de valider que le choix est 1, 2, 3 ou 4 (disons qu'il n'y a que 4 cursus, je n'ai plus le nombre en tête) dans ton code PHP, *avant* de l'envoyer à la BDD (sinon, la BDD contiendra des données incohérente, genre le cursus 42).
Avec un ENUM, tu peux laisser la BDD faire cette vérification (pour peu que les paramètres STRICT soient bien établis). Ta page devient <select><option value="MILITAIRE">Militaire</option><option value="COMMERCIAL">Commercial... et ton serveur PHP n'a (éventuellement) même plus besoin de valider l'entrée de l'utilisateur (ou juste leur existence): le code PHP passe la valeur entrée par l'utilisateur direct à la BDD, et si la BDD ne trouve pas cette valeur dans l'ENUM, alors elle lancera toute seule une exception (SIGNAL) que le code PHP catchera (si PDO est utilisé, c'est quasi-natif) et la valeur sera refusée à l'enregistrement. Perso, c'est ce que je fais sur Iamanoc (que j'ai un peu délaissé ces derniers mois :/ ): cela permet de faire moins de code et de le faire de manière plus sûre (on ne peut pas oublier un check ou une valeur de l'ENUM quand c'est la BDD qui fait directement les vérifications).
Note que, pour l'info, si plusieurs cursus pouvaient se faire en parallèle, "SET" aurait fonctionné tout pareil que ENUM (à la différence que SET permet de stocker plusieurs "valeurs" d'un ENUM en même temps, genre "MILITAIRE, COMMERCIAL" au lieu de juste l'un ou juste l'autre, cf https://dev.mysql.com/doc/refman/5.7/en/set.html )
Bonne création de jeu à toi