par
Cyrano » 30 oct. 2012, 10:56
...ce n'est ni "normalisé" (1ère règle normal, enum c'est mysql, etc) ni évolutif simplement (cf ta signature XD).
Pas normalisé, soit, mais c'est toujours utilisable dans la mesure où, quel que soit le SGBD utilisé, il existe une manière de le faire en utilisant un type normalisé et éventuellement un trigger ou une fonction utilisateur, voire pour certains SGBD un type défini par l'utilisateur. J'avais dans cet esprit monté une base sous Oracle avec des clé primaires auto-incrémentées alors que « AUTO_INCREMENT » n'existe pas dans Oracle. Faudrait-il se passer des facilités offertes par certains SGBD au seul prétexte que ce n'est pas dans une norme partagée par tous les SGBD ? Ce serait se limiter et se compliquer pas mal la tâche.
Pas évolutif, c'est à voir : est-ce que ça a vraiment besoin de l'être ? Ici, il s'agit de types de champs de formulaires, c'est donc limité par une norme définie par les DOCTYPE. Au pire, on pourrait prévoir de nouveaux types de champs, ce qui à priori est peu probable, mais rien n'interdit d'utiliser un type SET peut-être plus souple au lieu d'un type ENUM, ce qui permettrait d'ajouter les nouveaux types lorsqu'il en arrivera un nouveau tous les 36 du mois.
Le fait que le type ENUM soit propre à MySQL n'est pas bloquant à mon sens et ce type est approprié dans bien des cas. Suppose par exemple une table stockant des personnes avec nom, prénom et civilité : est-ce que pour stocker la civilité (M., Mme, Melle) tu feras une table à part ? Note que je l'ai déjà vu : sémantiquement, ce n'est certes pas faux, mais en pratique, ça me semble une aberration. Il n'y a qu'un cas où ça pourrait à la rigueur passer, c'est
ajoloca qui m'avait suggéré cette option, c'est dans le cas d'une application internationale où dans une table civilité, outre le libellé on aurait une colonne précisant la langue. Mais là, le problème de l'internationalisation ne se pose même pas puisque le même mot désigne une balise de code HTML qui sera toujours la même quelle que soit la langue affichée dans le site.
Je ne crois pas qu'il faille être trop à cheval sur certaines normes, faute de quoi, on passerait pour des intégristes bornés. C'est une question de circonstances, il faut de la logique et de la mesure en tout
my 2¢
[quote="moogli"]...ce n'est ni "normalisé" (1ère règle normal, enum c'est mysql, etc) ni évolutif simplement (cf ta signature XD).[/quote]
Pas normalisé, soit, mais c'est toujours utilisable dans la mesure où, quel que soit le SGBD utilisé, il existe une manière de le faire en utilisant un type normalisé et éventuellement un trigger ou une fonction utilisateur, voire pour certains SGBD un type défini par l'utilisateur. J'avais dans cet esprit monté une base sous Oracle avec des clé primaires auto-incrémentées alors que « AUTO_INCREMENT » n'existe pas dans Oracle. Faudrait-il se passer des facilités offertes par certains SGBD au seul prétexte que ce n'est pas dans une norme partagée par tous les SGBD ? Ce serait se limiter et se compliquer pas mal la tâche.
Pas évolutif, c'est à voir : est-ce que ça a vraiment besoin de l'être ? Ici, il s'agit de types de champs de formulaires, c'est donc limité par une norme définie par les DOCTYPE. Au pire, on pourrait prévoir de nouveaux types de champs, ce qui à priori est peu probable, mais rien n'interdit d'utiliser un type SET peut-être plus souple au lieu d'un type ENUM, ce qui permettrait d'ajouter les nouveaux types lorsqu'il en arrivera un nouveau tous les 36 du mois.
Le fait que le type ENUM soit propre à MySQL n'est pas bloquant à mon sens et ce type est approprié dans bien des cas. Suppose par exemple une table stockant des personnes avec nom, prénom et civilité : est-ce que pour stocker la civilité (M., Mme, Melle) tu feras une table à part ? Note que je l'ai déjà vu : sémantiquement, ce n'est certes pas faux, mais en pratique, ça me semble une aberration. Il n'y a qu'un cas où ça pourrait à la rigueur passer, c'est [b]ajoloca[/b] qui m'avait suggéré cette option, c'est dans le cas d'une application internationale où dans une table civilité, outre le libellé on aurait une colonne précisant la langue. Mais là, le problème de l'internationalisation ne se pose même pas puisque le même mot désigne une balise de code HTML qui sera toujours la même quelle que soit la langue affichée dans le site.
Je ne crois pas qu'il faille être trop à cheval sur certaines normes, faute de quoi, on passerait pour des intégristes bornés. C'est une question de circonstances, il faut de la logique et de la mesure en tout ;)
my 2¢
