Et là dessus je voudrai ajouter des feedbacks pour toutes les sections, la table serai la même pour les 3. Est ce que je dois la dédoubler (voir tripler) pour chaque table, (Feedback_Programme, Feedback_Module, Feedback_Cours)
Si c’est pour avoir le feedback pour les Cours, une table Feedback ( id, texte, cours_id)-(et si j’ai bien tout pigé au schéma, les cours appartiennent a un module, qui appartient a un programme, j’ai bon ?). Si tu veux un feedback par catégorie, je ne vois que la solution “Feedback_programme”, “Feedback_module”, “Feedback_cours”, vu que meme si ça correspond vaguement a la meme notion (du feedback), ils sont conceptuellement tous différents (un feedback de programme n’est pas un feedback de module).
@ Sh8an > un champ feedback par table implique que tu ne peux recevoir qu’un seul et unique feedback par item (ou alors si ça n’est pas le cas, tu violes une des NF mais je les ai pas en tete) . Or là, je pense que la problématique est plutot de collecter plusieurs feedbacks.
EDIT : en y reflechissant, j’ai l’impression qu’il manque les users. Du style Personne (id, nom, prénom), et que ce sont eux qui fournissent les feedbacks. S’il n’ont qu’un feedback par Cours / Module / Programme a donner, une relation par bidule du style : Donne_Feedback_Cours ( #cours_id, #personne_id, feedback) // Donne_Feedback_Module ( #module_id, #personne_id, feedback) // Donne_Feedback_Programme ( #programme_id, #personne_id, feedback). S’il y’a la possibilité d’en donner plusieurs, un date en primary key dans la relation …
Si tu tiens à avoir des FK pour chaque table, il te faut une table Feedback avec une colonne (nullable) par table référencée (ProgramId, ModuleId, CoursId). L’une des 3 colonnes sera renseignée fonction du rattachement.
Par contre, les règles qui en découlent (pas plus d’un Id renseigné, au moins un Id renseigné) ne pourront être gérées dans ta BDD que par trigger ou insertion par procédure stockée. Sinon il te faudra implémenter cette logique dans ton appli.
[quote=« Styx31, post:4, topic: 47449 »]Si tu tiens à avoir des FK pour chaque table, il te faut une table Feedback avec une colonne (nullable) par table référencée (ProgramId, ModuleId, CoursId). L’une des 3 colonnes sera renseignée fonction du rattachement.
Par contre, les règles qui en découlent (pas plus d’un Id renseigné, au moins un Id renseigné) ne pourront être gérées dans ta BDD que par trigger ou insertion par procédure stockée. Sinon il te faudra implémenter cette logique dans ton appli.[/quote]
ça pourrait etre la solution, mais en mysql, on ne peut avoir de PK non renseigné, comme on ne peut avoir de table sans PK. Donc, je pense que je vais me diriger vers ça:
c’est ce que j’avais pensé au début, mais je voulais voir s’il n’y avait pas un moyen de simplifier tout ça. Visiblement Non!
une table feedback_programme avec id_feedback et id_programme.
une table feedback_module avec id_feedback et id_module.
une table feedback_cours avec id_feedback et id_cours.
éventuellement, un champ “type” dans la table feedback contenant programme, module ou cours.
ça, je pense que c’est la bonne solution! bon apres c’est un peu dégueulasse, parce que il n’y a pas de relation « directe » entre les deux tables, mais sinon c’est pas mal, y’a des contraintes check en mySQL?
[quote]une table feedback.
une table feedback_programme avec id_feedback et id_programme.
une table feedback_module avec id_feedback et id_module.
une table feedback_cours avec id_feedback et id_cours.[/quote]
pour le champ type, je disais ça en plus de reste. parce que ça te permet de savoir dans quelle table chercher lorsque tu veux retrouver l’enregistrement concerné par le feedback.
:crying: