Discussion :

[nine]

bonjour

je suis face a un dileme :

soit je fais 4 tables correspondant à 4 enquetes portant sur des elevages (bovin, ovin,...)
et j'ai toutes les reponses au questionnaire dans une table : elevage_bovin, ou elevage_ovin etc

ou alors :

je fais 1 table elevage (avec nom de l'exploitation, commune, etc ...9 colonnes)
--> liée au questionnaire adéquat (questionnaire_bovin, questionnaire_ovin, etc ...) avec une contrainte inter-relation 1/N de type XT (s'exclue mutuellement, 1 obligatoire)

donc j'aurai :
table elevage : elevage_id en PK et questionnaire_1_2__3_4 (4 fois) en FK
table questionnaire_ovin : avec questionnaire_ovin_id en PK
table questionnaire_bovin :avec questionnaire_bovin_id en PK
etc

question :
j'aurai 3 FK questionnaire_id nulles et une FK non nulle liée à un questionnaire , c'est bien ça ?

Pour lister tous les elevages de type ovin , on devra faire :

SELECT .....
FROM ELEVAGE T1, questionnaire_bovin T2
WHERE T1.questionnaire_ovin_id = T2.questionnaire_ovin_id

Savoir combien d'elevage ovin, bovin : select count(ovin_id)

La question : vaut mieux 4 tables ou la deuxieme solution ?
pour lister tous les elevages : vaut mieux 4 unions (1er cas de figure) ou 1 requete avec 4 jointures ?

je n'aurai que 100 elevages. et donc que 100 questionnaires

Merci à tous d'avance


nine

[escartefigue]

Bonjour,

Si par exemple certaines questions sont communes à tous les types d'élevage, et d'autres sont spécifiques, alors mutualisez la partie commune dans une entité-type (qui deviendra une table) "QUESTIONNAIRE", puis faites autant de sous-type (qui deviendront chacun des tables) que de types d'élevage qui nécessitent des questions spécifiques
Si maintenant, pour un type d'élevage particulier, il y a très peu d'éleveurs, et seulement une ou deux questions spécifiques, vous pouvez fusionner ce type avec un autre et rendre la réponse nullable
Ce qu'il ne faut pas faire, c'est une table unique, si de nombreux attributs sont spécifiques à seulement certains types d'élevage (pas de table "fourre tout")

EDIT : si vous avez un grand nombre de types de questionnaires différents, vous pouvez modéliser un contenu dynamique en procédant comme suit :
QUESTIONNAIRE 1,n --- Comporter --- 0,n QUESTION 0,n --- Concerner --- 1,n TYPE ELEVAGE

[nine]

merci pour votre reponse.

je n'aurai que 4 types d'elevage et donc 4 questionnaires type.

votre reponse penche alors vers la solution 1 ?

avec les tables :

QUESTIONNAIRE_1
QUESTIONNAIRE_2
QUESTIONNAIRE_3
QUESTIONNAIRE_4

eventuellement une table generique QUESTIONNAIRE qui serai liee à l'une des 4 tables questionnaire , c'est bien ça ? Mais en fait là, ca revient au cas de figure n°2 ?

sachant que je dois rendre le projet rapidement, qu'il ne servira qu'une fois, que j'ai 4 types de questionnaire/elevage (avec env 50 questions ) pour un total de 100 fermes.
je dois me decider vite ! coté appli : un seul formulaire avec les 50 questions.

encore merci,

nine

[escartefigue]

Pour savoir quel choix retenir, faites la liste des questions
- 1ère liste : questions communes à tous les questionnaires
- 2ème, 3ème, 4ème et 5ème liste : questions spécifiques à chaque questionnaire
Si les spécifiques sont nombreuses, faites des tables spécifiques, s'il y en a très peu, vous pouvez mettre tout dans une seule table

Par contre, il faut avoir à l'esprit que, avec une table unique, c'est très peu évolutif. Si demain de nouvelles questions apparaissent qui ne concerne que les ovins, les bovins et autres élevages seront impactés inutilement
Il sera en ce cas nécessaire de séparer (et donc revenir à la solution multi-tables)

[nine]

Par contre, il faut avoir à l'esprit que, avec une table unique, c'est très peu évolutif. Si demain de nouvelles questions apparaissent qui ne concerne que les ovins, les bovins et autres élevages seront impactés inutilement
Il sera en ce cas nécessaire de séparer (et donc revenir à la solution multi-tables)

là je ne comprends pas .... si il y a une table/elevage : les autres tables ne seront pas impactées ?!

voici grossierement ce à quoi je pensais :



donc si demain (mais comme je l'ai dit ce projet est à usage unique) on ajoute des questions pour les ovin_lait, cela n'impactera que les ovin_lait : on ajoute des colonnes, pour les enregistrement plus anciens, on aura des null pour valeur.

Je voudrais faire bien et etre sur que cette solution, sans etre la meilleure, fonctionnera bien et vite (je n'ai pas codé une seule ligen encore :-( ....) !

Merci encore

[escartefigue]

Il s'agit de votre solution 1 qui je le répète, est tout à fait acceptable si les questions sont différentes entre les différents élevages

Je pensais avoir été clair dans mes explications, désolé si ce n'était pas le cas quand je disais "par contre etc..." ca concernait l'autre solution, celle avec une seule table

[nine]

ok, merci pour tout.
en fait, il y a beaucoup de redondance mais je vais quand meme partir sur cette solution, le formulaire est très long, de ce fait j'avais dit 50 questions mais il y a des tableaux avec beaucoup de valeurs dedans. Au final je viens de finir mon CREATE TABLE, il y a 405 champs ... si je met un bout par ci un bout par là et des requetes de jointure dans tous les sens je vais y passer beaucoup plus de temps, pour au final une seule utilisation et 10 jours pour coder tout ça ....
encore merci pour votre patience et bonne soirée,

nine