Conception de base de données pour une enquête

Question

J'ai besoin de créer un sondage dans lequel les réponses sont stockées dans une base de données. Je me demande quelle serait la meilleure façon de mettre en œuvre la présente dans la base de données, spécifiquement les tables nécessaires. L'enquête contient différents types de questions. Par exemple: les champs de texte pour les commentaires, questions à choix multiples, et, éventuellement, des questions qui pourraient contenir plus d'une réponse (c'est à dire cocher toutes les cases qui s'appliquent).

Je suis venu avec deux solutions possibles:

1. Créer un géant de la table qui contient les réponses pour chaque enquête de soumission. Chaque colonne correspondent à une réponse de la de l'enquête. c'est à dire SurveyID, Answer1, Answer2, Answer3

   Je ne pense pas que c'est la meilleure façon puisqu'il y a beaucoup de questions dans cette enquête, et il ne semble pas très flexible si l'enquête est à changer.

2. L'autre chose que j'ai pensé de a été la création d'une table Question et Réponse table. La question table contiennent toutes les questions pour le de l'enquête. La table de réponse devrait contenir les réponses individuelles de l'enquête, chaque ligne lié à une question.

   Un exemple simple:

   tblSurvey: SurveyID

   tblQuestion: QuestionID, SurveyID, QuestionType, Question

   tblAnswer: AnswerID, UserID, QuestionID, Réponse

   tblUser: nom d'utilisateur, nom d'utilisateur

   Mon problème, c'est qu'il n'y peut être des tonnes de réponses qui seraient faire la table de Réponse assez énorme. Je ne suis pas sûr que ce soit si grand quand il s'agit de la performance.

Je te remercie de toutes les idées et suggestions.

Answer 1

Je pense que votre modèle n ° 2 est très bien, cependant, vous pouvez prendre un coup d'oeil au modèle plus complexe qui stocke les questions et les pré-faites réponses (réponses) et leur permet d'être ré-utilisés dans les différentes enquêtes.

- Une enquête peut avoir de nombreuses questions, une question peut être (ré)utilisé dans de nombreuses enquêtes.
- Un (pré) réponse peut être offert pour de nombreuses questions. Une question peut avoir plusieurs réponses. Une question peut avoir différentes réponses offertes dans les différentes enquêtes. Une réponse peut être offert à des questions différentes dans les différentes enquêtes. Il y a un défaut "d'Autres" réponse, si une personne choisit d'autres, sa réponse est enregistrée dans la Réponse.OtherText.
- Une personne peut participer à de nombreuses enquêtes, une personne peut répondre à certaines question dans un sondage qu'une seule fois.

Answer 2

Certainement l'option n ° 2, je pense aussi qu'on peut avoir une surveillance dans le schéma actuel, vous pourriez vouloir un autre tableau:

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

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

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

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

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

Chaque question va probablement avoir un nombre de réponses que l'utilisateur peut sélectionner à partir, puis les réponses vont être suivis dans une autre table.

Les bases de données sont conçus pour stocker beaucoup de données, et la plupart échelle très bien. Il n'y a pas de réel besoin à l'utilisateur une moindre forme normale simplement pour économiser sur l'espace.

Answer 3

En règle générale, la modification de schéma basé sur quelque chose qu'un utilisateur peut modifier (comme l'ajout d'une question à une enquête) doit être considéré comme assez puant. Il y a des cas où il peut être approprié, en particulier lorsque de grandes quantités de données, mais de savoir ce que vous obtenez en avant de vous plonger dans. Avoir juste un "réponses" de la table pour chaque enquête signifie que l'ajout ou la suppression des questions est potentiellement très coûteux, et il est très difficile de faire des analyses dans une question-de façon agnostique.

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

1. Créer des réponses détaillées des tables pour stocker les par-question réponses, comme vous l'avez décrit dans la section 2. Ces données ne sont généralement pas directement interrogée à partir de votre application, mais pourrait être utilisé pour générer des données de synthèse pour les tableaux de présentation. Vous auriez probablement souhaitez également mettre en œuvre une certaine forme de l'archivage ou à la radiation de ces données.
2. Aussi créer la table des réponses à partir de 1 si nécessaire. Ceci peut être utilisé chaque fois que les utilisateurs veulent voir une simple table de résultats.
3. Pour toutes les analyses qui doivent être faites à des fins de reporting, la planification des travaux en vue de créer de nouvelles données de synthèse sur la base des données à partir de 1.

C'est absolument beaucoup plus de travail à mettre en œuvre, donc, je ne le conseille pas si vous ne savez pas certain que ce tableau va courir à grande échelle des préoccupations.

Answer 4

N ° 2 a l'air bien.

Pour une table avec seulement 4 colonnes, il ne devrait pas être un problème, même avec un bon quelques 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, puis il aurait pas de problème.

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

Bien sûr, vous devez spécifier la Base de données que vous utilisez ainsi que l'estimation des volumes.

Answer 5

La deuxième approche est la meilleure.

Si vous voulez normaliser en outre, vous pouvez créer une table pour les types de question

Les choses simples à faire sont:

• Placez la base de données et les journaux sur leur propre disque, pas tous sur C comme valeur par défaut
• Créer la base de données aussi grand que nécessaire, donc vous n'avez pas de pauses, tandis que la base de données augmente

Nous avons eu du journal des tables dans SQL Server le Tableau avec 10 millions de lignes.