Discussion :

[bibile]

Bonjour,

J'ai besoin d'un conseil sur la conception de mes tables.

c'est un site avec des questions et des reponses.
l'utilisateur peux poser une question et proposer des reponses.

les questions sont independantes les unes des autres.
Une question peut avoir plusieurs reponses.

j'ai une table sur les questions, du type:
ID, Question, Date, PropietaireDeLaQuestion, ...

et je voulais faire une table de reponses pour chaque question.
avec par exemple:
Reponse1, Reponse2, Reponse3, Reponse4, Reponse5
si il y avait 5 reponses pour la question.
si il y a moins ou plus de reponses, la table aura plus ou moins de champs.

Ca me permet de stocker le detail des reponses de tous les utilisateurs.

mon probleme est que ca ne me semble pas une bonne idee de creer une table a chaque fois que j'ajoute une question. je pourrais faire une seule table pour toutes les reponses si il y avait tjrs le meme nbre de reponses par question, mais ce n'est pas le cas.

Est-ce qu'il y a une meilleure facon de le faire ?

merci !

PS: pour ceux qui ne connaissent pas, un lien interessant sur les bdd http://www.databaseanswers.org/data_models/index.htm

[pcaboche]

Bonsoir,

Ca fait un petit moment que je n'étais pas venu sur le forum MySQL. Par contre, je ne fait que passer...

Pour le questionnaire, on peut faire comme cela:

Table question :
id, enonce, idProprietaire*, dateQuestion, ...

Table reponse_possible :
id, idQuestion*, intitule, ...

Table reponse:
idQuestion*, idReponse*, idUtilisateur*

---------------
Légende:
soulignement => clef primaire
etoile* => clef étrangère

[bibile]

merci pour ta reponse

ca me semble une bonne methode si l'utilisateur ne peut choisir qu'une seule reponse par question. si il peut en choisir plus (de 1 a l'infini theroiquement, ca depend des questions...) et bien ta proposition ne fonctionne plus, je pense

[supernova]

Bonjour,

une table question :
idQuestion, libelleQuestion, texteQuestion (clé idQuestion)

une table reponse :
idReponse, libelleReponse, texteReponse (clé idReponse)

une table de jointure
idQuestion, idReponse (clé idQuestion,idReponse)

[pcaboche]

ca me semble une bonne methode si l'utilisateur ne peut choisir qu'une seule reponse par question. si il peut en choisir plus (de 1 a l'infini theroiquement, ca depend des questions...) et bien ta proposition ne fonctionne plus, je pense

Faux. Voici les deux cas de figure:

1) Plusieurs réponses possibles par question:

Table reponse:
idQuestion*, idUtilisateur*, idReponse*


2) Une seule réponse possible par question:

Table reponse:
idQuestion*, idUtilisateur*, idReponse*


La différence se situe au niveau des champs constituant la clef primaire.

[bibile]

Faux. Voici les deux cas de figure:

1) Plusieurs réponses possibles par question:
Table reponse:
idQuestion*, idUtilisateur*, idReponse*


2) Une seule réponse possible par question:
Table reponse:
idQuestion*, idUtilisateur*, idReponse*


La différence se situe au niveau des champs constituant la clef primaire.

ha
je crois que j'ai compris.
dans le cas d'un site ou on peut avoir 1 ou plusieurs reponses par questions, alors il faut utiliser idQuestion*, idUtilisateur*, idReponse*
sinon, il faut utiliser idQuestion*, idUtilisateur*, idReponse*

ok. je vais reflechir un peu plus a ta solution, parce qu'il faut aussi que les tables soient definies de facon a faciliter le traitement par la suite.

d'une maniere generale, est-ce que tu peux me confirmer qu'il vaut mieux avoir qques tres grandes tables plutot qu'un tres grand nbre de petites tables ?
merci !

-> supernova : je ne comprends pas la difference entre Libellé et Texte dans ton exemple.

[pcaboche]

ha
je crois que j'ai compris.
dans le cas d'un site ou on peut avoir 1 ou plusieurs reponses par questions, alors il faut utiliser idQuestion*, idUtilisateur*, idReponse*
sinon, il faut utiliser idQuestion*, idUtilisateur*, idReponse*

Ce qui serait bien, ce serait que tu aies compris pourquoi on a ces deux réponses différentes (avec des exemples pour argumenter) et de comprendre comment on en est arrivé à ce résultat.

ok. je vais reflechir un peu plus a ta solution, parce qu'il faut aussi que les tables soient definies de facon a faciliter le traitement par la suite.

Ca dépend de ton problème (combien de réponses possibles (min-max) pour chaque question ? Peut-on donner plusieurs réponses? Si oui, combien au maximum? Est-ce que le modèle sera amené à évoluer? Quel type de traitement on souhaite effectuer par la suite? etc.).

Voilà donc la solution générale (peut faire face à tous les cas de figure et est donc évolutive).

d'une maniere generale, est-ce que tu peux me confirmer qu'il vaut mieux avoir qques tres grandes tables plutot qu'un tres grand nbre de petites tables ?
merci !

Déjà, il faut savoir ce que l'on entend par "grand":
- ça peut être "grand" de par la taille des enregistrements. Ici, ce n'est pas la cas, les différentes clefs étant des entiers, or les entiers, ça ne prend pas beaucoup de place... (2 à 4 octets, c'est pas la mer à boire...)
- ça peut être "grand" de par le nombre d'enregistrements, mais une base de données, c'est un peu fait pour ça à la base... (dans la limite du raisonnable)


Multiplier le nombre de tables (genre une table par question) n'est pas une bonne chose. Déjà, ce n'est pas correct sur le plan de la conception. Ensuite, je crois qu'il doit y avoir des limitations sur le nombre de tables que l'on peut créer dans une BDD. Enfin, si c'est pour une question de traitement, sache qu'il y a les index qui sont fait pour cela et qui accélèrent les recherches et les jointures.