Conception de la base de données pour une enquête [fermé]

J'ai besoin de créer une enquête dans laquelle les réponses sont stockées dans une base de données. Je me demande simplement quelle serait la meilleure façon de l'implémenter dans la base de données, en particulier les tables requises. L'enquête contient différents types de questions. Par exemple: des champs de texte pour les commentaires, des questions à choix multiples et éventuellement des questions pouvant contenir plus d'une réponse (cochez tout ce qui s'applique).

J'ai proposé deux solutions possibles:

1. Créez un tableau géant contenant les réponses pour chaque soumission d'enquête. Chaque colonne correspondrait à une réponse de l'enquête. ie SurveyID, Answer1, Answer2, Answer3

   Je ne pense pas que ce soit la meilleure façon car il y a beaucoup de questions dans cette enquête et ne semble pas très flexible si l'enquête doit changer.

2. L'autre chose à laquelle j'ai pensé était de créer une table de questions et une table de réponses. Le tableau de questions contiendrait toutes les questions de l'enquête. Le tableau des réponses contiendrait les réponses individuelles de l'enquête, chaque ligne étant liée à une question.

   Un exemple simple:

   tblSurvey : SurveyID

   tblQuestion : QuestionID, SurveyID , QuestionType, Question

   tblAnswer : AnswerID, UserID , QuestionID , réponse

   tblUser : UserID , UserName

   Mon problème avec ceci est qu'il pourrait y avoir des tonnes de réponses qui rendraient la table de réponse assez énorme. Je ne suis pas sûr que ce soit si génial en termes de performances.

J'apprécierais toutes les idées et suggestions.

Je pense que votre modèle n ° 2 est bon, mais vous pouvez jeter un œil au modèle plus complexe qui stocke les questions et les réponses pré-faites (réponses proposées) et leur permet d'être réutilisées dans différentes enquêtes.

- Une enquête peut comporter plusieurs questions; une question peut être (ré) utilisée dans de nombreuses enquêtes.
- Une réponse (prédéfinie) peut être proposée pour de nombreuses questions. Une question peut avoir plusieurs réponses proposées. Une question peut avoir différentes réponses proposées dans différentes enquêtes. Une réponse peut être proposée à différentes questions dans différentes enquêtes. Il existe une réponse par défaut «Autre», si une personne en choisit une autre, sa réponse est enregistrée dans Answer.OtherText.
- Une personne peut participer à de nombreuses enquêtes, une seule personne ne peut répondre qu'une seule fois à une question spécifique d'une enquête.

Ma conception est illustrée ci-dessous.

Le dernier script de création se trouve sur https://gist.github.com/durrantm/1e618164fd4acf91e372

Le script et le fichier mysql workbench.mwb sont également disponibles sur
https://github.com/durrantm/survey

Certainement l'option n ° 2, je pense également que vous pourriez avoir un oubli dans le schéma actuel, vous voudrez peut-être une autre table:

+-----------+
| tblSurvey |
|-----------|
| SurveyId  |
+-----------+

+--------------+
| tblQuestion  |
|--------------|
| QuestionID   |
| SurveyID     |
| QuestionType |
| Question     |
+--------------+

+--------------+
| tblAnswer    |
|--------------|
| AnswerID     |
| QuestionID   |
| Answer       |
+--------------+

+------------------+
| tblUsersAnswer   |
|------------------|
| UserAnswerID     |
| AnswerID         |
| UserID           |
| Response         |
+------------------+

+-----------+
| tblUser   |
|-----------|
| UserID    |
| UserName  |
+-----------+

Chaque question aura probablement un nombre défini de réponses parmi lesquelles l'utilisateur pourra choisir, puis les réponses réelles seront suivies dans un autre tableau.

Les bases de données sont conçues pour stocker beaucoup de données et la plupart évoluent très bien. Il n'est plus vraiment nécessaire d'utiliser une forme normale inférieure simplement pour économiser de l'espace.

En règle générale, la modification d'un schéma en fonction de quelque chose qu'un utilisateur pourrait changer (comme l'ajout d'une question à une enquête) doit être considérée comme assez malodorante. Dans certains cas, cela peut être approprié, en particulier lorsque vous traitez de grandes quantités de données, mais sachez dans quoi vous vous embarquez avant de vous lancer. Le simple fait de disposer d'un tableau de "réponses" pour chaque enquête signifie que l'ajout ou la suppression de questions est potentiellement très coûteux. , et il est très difficile de faire des analyses de manière indépendante des questions.

Je pense que votre deuxième approche est la meilleure, mais si vous êtes certain que vous allez avoir beaucoup de problèmes d'échelle, une chose qui a fonctionné pour moi dans le passé est une approche hybride:

1. Créez des tableaux de réponses détaillés pour stocker les réponses par question comme vous l'avez décrit dans 2. Ces données ne sont généralement pas directement interrogées depuis votre application, mais sont utilisées pour générer des données récapitulatives pour les tableaux de rapport. Vous voudrez probablement également mettre en œuvre une forme d'archivage ou de suppression de ces données.
2. Créez également le tableau des réponses à partir de 1 si nécessaire. Cela peut être utilisé chaque fois que les utilisateurs veulent voir un tableau simple pour les résultats.
3. Pour toute analyse qui doit être effectuée à des fins de reporting, planifiez des tâches pour créer des données récapitulatives supplémentaires basées sur les données de 1.

C'est absolument beaucoup plus de travail à mettre en œuvre, donc je ne le conseillerais vraiment pas à moins que vous ne sachiez avec certitude que ce tableau va rencontrer des problèmes à grande échelle.

La deuxième approche est la meilleure.

Si vous souhaitez le normaliser davantage, vous pouvez créer un tableau pour les types de questions

Les choses simples à faire sont:

• Placez la base de données et connectez-vous sur leur propre disque, pas tous sur C par défaut
• Créez la base de données aussi grande que nécessaire pour ne pas avoir de pauses pendant que la base de données se développe

Nous avons eu des tables de journal dans SQL Server Table avec des dizaines de millions de lignes.

Le n ° 2 a l'air bien.

Pour une table avec seulement 4 colonnes, cela ne devrait pas être un problème, même avec quelques bons millions de lignes. Bien sûr, cela peut dépendre de la base de données que vous utilisez. Si c'est quelque chose comme SQL Server, ce ne serait pas un problème.

Vous voudrez probablement créer un index sur le champ QuestionID, sur la table tblAnswer.

Bien sûr, vous devez spécifier la base de données que vous utilisez ainsi que les volumes estimés.

Ça a l'air assez complet pour une petite enquête. N'oubliez pas d'ajouter un tableau pour les «valeurs ouvertes», où un client peut donner son avis via une zone de texte. Liez cette table avec une clé étrangère à votre réponse et placez des index sur toutes vos colonnes relationnelles pour les performances.

Le numéro 2 est correct. Utilisez la conception correcte jusqu'à ce que et sauf si vous détectez un problème de performances. La plupart des SGBDR n'auront pas de problème avec une table étroite mais très longue.

Avoir une grande table de réponses, en soi, n'est pas un problème. Tant que les index et les contraintes sont bien définis, ça devrait aller. Votre deuxième schéma me semble bon.

Étant donné l'index approprié, votre deuxième solution est normalisée et bonne pour un système de base de données relationnelle traditionnel.

Je ne sais pas à quel point c'est énorme, mais cela devrait contenir sans problème quelques millions de réponses.

Vous pouvez choisir de stocker l'ensemble du formulaire sous forme de chaîne JSON.

Je ne suis pas sûr de vos besoins, mais cette approche fonctionnerait dans certaines circonstances.