Conception de base de données pour une enquête
J'ai besoin de créer une enquête où les réponses sont stockées dans une base de données. Je me demande simplement quel serait le meilleur moyen d'implémenter cela 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 (c’est-à-dire, cochez toutes les réponses qui s'appliquent).
J'ai proposé deux solutions possibles:
Créez un tableau géant contenant les réponses pour chaque envoi d'enquête. Chaque colonne correspondrait à une réponse du sondage. c'est-à-dire SurveyID, Answer1, Answer2, Answer3
Je ne pense pas que ce soit la meilleure façon, car il y a beaucoup de questions dans ce sondage et ne semble pas très flexible si le sondage doit changer.
L'autre chose à laquelle j'ai pensé était de créer un tableau de questions et un tableau de réponses. La table de questions contiendrait toutes les questions de l'enquête. Le tableau des réponses contiendrait les réponses individuelles du sondage, chaque ligne étant liée à une question.
Un exemple simple:
tblSurvey: SurveyID
tblQuestion: QuestionID, SurveyID , QuestionType, Question
tblAnswer: AnswerID, UserID , QuestionID , Répondre
tblUser: ID utilisateur, nom d'utilisateur
Mon problème avec ceci est qu'il pourrait y avoir des tonnes de réponses qui rendraient le tableau des réponses assez énorme. Je ne suis pas sûr que ce soit si génial quand il s'agit de performance.
J'apprécierais toutes les idées et suggestions.
Je pense que votre modèle n ° 2 est correct, mais vous pouvez jeter un coup d'œil au modèle plus complexe qui stocke des questions et des réponses prédéfinies (réponses proposées) et permet de les réutiliser dans différentes enquêtes.
- Une enquête peut comporter de nombreuses questions. une question peut être (ré) utilisée dans de nombreuses enquêtes.
- Une réponse (déjà établie) 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 "Autre" par défaut. Si une personne en choisit une autre, sa réponse est enregistrée dans Answer.OtherText.
- Une personne peut participer à plusieurs enquêtes, une personne ne peut répondre à une question spécifique d’une enquête qu’une fois.
Ma conception est montrée ci-dessous.
Le dernier script de création est à l’adresse https://Gist.github.com/durrantm/1e618164fd4acf91e372
Le script et le fichier mysql workbench.mwb sont également disponibles à l'adresse suivante:
https://github.com/durrantm/survey 
Certainement l'option n ° 2, je pense aussi 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'y a pas de réel besoin d'utiliser un plus petit forme normale 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 modifier (par exemple, l'ajout d'une question à une enquête) devrait être considérée comme assez odorante. Il y a des cas où cela peut être approprié, en particulier lorsque vous manipulez de grandes quantités de données, mais sachez dans quoi vous vous engagez avant de plonger dedans. Avoir juste 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 de l’analyse sans poser de 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:
- Créez des tableaux de réponses détaillés pour stocker les réponses à chaque question comme vous l'avez décrit à l'étape 2. Ces données ne seraient généralement pas directement interrogées à partir de votre application, mais seraient 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 d'extinction pour ces données.
- Créez également le tableau de réponses à partir de 1 si nécessaire. Ceci peut être utilisé chaque fois que les utilisateurs veulent voir un tableau simple pour obtenir des résultats.
- Pour toute analyse à effectuer à des fins de rapport, planifiez les travaux pour créer des données récapitulatives supplémentaires en fonction des données de 1.
C’est beaucoup plus de travail à mettre en œuvre, je ne vous le déconseillerai donc que si vous êtes certain que ce tableau risque de poser des problèmes énormes.
No 2 semble bien.
Pour une table avec seulement 4 colonnes, cela ne devrait pas poser de 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, alors 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.
La deuxième approche est la meilleure.
Si vous voulez normaliser davantage, vous pouvez créer une table 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 tant que la base de données s'agrandit
Nous avons eu des tables de journal dans SQL Server Table avec 10 millions de lignes.
Semble assez complet pour une enquête de type. N'oubliez pas d'ajouter un tableau pour les "valeurs ouvertes", dans lequel un client peut donner son avis via une zone de texte. Liez cette table avec votre clé étrangère à votre réponse et placez des index sur toutes vos colonnes relationnelles pour améliorer les performances.
Le numéro 2 est correct. Utilisez la conception correcte jusqu'à et sauf si vous détectez un problème de performance. 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, tout va bien. Votre deuxième schéma me semble bien.
Avec la bonne index, votre deuxième solution est normalisée et convient à un système de base de données relationnelle traditionnel.
Je ne sais pas à quel point c'est énorme, mais il devrait contenir sans problème quelques millions de réponses.