Qu'est-ce qu'un moyen efficace de stocker un questionnaire dans une base de données?

Question

Puisque les questionnaires peuvent toujours changer et que les questions elles-mêmes peuvent être longues, il semble stupide d'utiliser des questions comme noms de colonnes. Existe-t-il une convention ou une méthode éprouvée pour stocker un questionnaire dans une base de données?

Je pensais avoir une table avec (Question-ID, Question) et ensuite une deuxième table pour la question-id et la réponse. Mais cette solution peut être trop lente car une troisième jointure serait nécessaire pour joindre les questions à un utilisateur particulier.

Answer 1

Qu'est-ce qui ne va pas avec une jointure? C'est tout le point d'une base de données relationnelle, une jointure.

Stockez les questions dans un tableau.

Stockez les questions dans un autre tableau.

Si les réponses sont prédéfinies et sont communes parmi plus d'une question, stockez les réponses communes dans leur propre table et créez une autre table qui a un QuestionID avec un AnswerID. N'ayez pas peur des jointures, elles font partie des bases de données relationnelles. Sans jointures, vous ne faites que traiter des fichiers plats.

Answer 2

Je pense que la meilleure réponse possible est de modéliser l'information sur laquelle porte le questionnaire. N'essayez pas de modéliser le questionnaire lui-même - le questionnaire n'est que le moyen utilisé pour rassembler le contenu de la base de données.

Answer 3

Je pense qu'il serait préférable d'avoir une classe/fichier séparé représentant le questionnaire en utilisant un hashmap. Et puis d'autres classes peuvent l'utiliser. Je ne vois pas vraiment le besoin de stocker les questions dans la base de données car elles seraient encore chargées dans un hashmap.

Answer 4

J'ai un peu de retard avec ma réponse, mais peut-être que quelqu'un trouvera cette information utile.

Je suis entièrement d'accord avec JonH. Je vais juste donner un exemple de la façon dont je l'ai mis en œuvre pour rendre la solution commune plus claire.

Les tables les plus courantes sont:

1. Questions: Id (PK), Question, Description, orderNumber, SectionId (FK à QuestionsSections.Id), AnswerTypeId (FK) à AnswerType.Id
2. Réponses : Id (PK), réponse, SubmitDate, UserId (FK à Users.Id), QuestionID (FK à Questions.Id)
3. Questionnaire: Id (PK), Nom, description
4. QuestionnaireQuestions: QuestionnaireId (PK, FK au Questionnaire.Id), QuestionId (PK, FK à Questions.Id)
5. QuestionsSections: Id (PK), Nom, Description, OrderNumber
6. AnswerType: Id (PK), type, Description

plus, vous pouvez préférer créer table spéciale pour les réponses une option d'achat (par exemple radios, cases à cocher, etc.), ou table de suivi d'activité, en fonction des besoins de votre application.

---

Voici les liens qui peuvent être utiles (séquence proposée pour la lecture de haut en bas):

• Questionnaire database design - which way is better?
• Database Design: Web Polls
• How to keep long multiple of questions and answers in database?
• Designing a database to hold a number of questionnaire definitions