Existe-t-il un meilleur moyen de structurer une table SQL traitant des questionnaires d'utilisateur?

J'ai un formulaire de divulgation qui oblige un utilisateur à entrer des réponses oui/non pour une série d'environ 30 questions.Existe-t-il un meilleur moyen de structurer une table SQL traitant des questionnaires d'utilisateur?

Existe-t-il une meilleure façon de créer la table que d'avoir 30 colonnes qui correspondent aux questions? Ci-dessous est mon script MS-SQL, mais la question concerne plus la structure que la syntaxe.

CREATE TABLE Questionaire(
    QuestionaireID int IDENTITY(1,1) NOT NULL, 
    UserID int NOT NULL, 
    Q1 bit NOT NULL, 
    Q2 bit NOT NULL, 
    Q3 bit NOT NULL, 
    ... etc ... 
    ... etc ... 
    Q30 bit NOT NULL 
) 

-- and to store the questions relating to Q1, Q2, etc... 
CREATE TABLE Questions(
    QuestionID int IDENTITY(1,1) NOT NULL, 
    Question varchar(30) NOT NULL 
)

Source

2009-08-16 Joshua

bien, il y a 2 meilleures idées que je peux penser:

magasin un vecteur (par exemple une variable de tableau chaîne/octet contenant tous les résultats), et gérer tout ce qui concerne les données dans votre programme (de cette façon, vous êtes plus limité sur les requêtes SQL)
stocker la paire clé/valeur, saisie par l'identifiant d'enquête, par ex.

1134 68 ans

1134 préfèrent chocolat

1134 largeur 6"

1135 age 31

1135 préfèrent vanille

largeur 1135 3,2"

cela dépend de ce que vous voulez faire avec les résultats. mais cela est plus « correcte » que ce que vous avez dit, depuis ma dernière option que vous êtes moins susceptible de rencontrer des problèmes

Source

2009-08-16 00:23:09

Quel est l'avantage de réduire l'utilisation de SQL? Vous l'avez déclaré comme donné. –

Merci. J'ai envisagé de stocker JSON/XML dans un champ, mais le reporting sur ces données serait difficile pour moi. Toutes les questions ont des réponses oui/non comme mentionné et toutes les réponses devraient être «non». Peut-être que la meilleure approche serait de stocker simplement des réponses «notables», c'est-à-dire lorsque l'utilisateur sélectionne «Oui» à une question. Alors ID, UserID, QuestionID suffirait? – Joshua

Cette réponse m'a aidé à arriver à la conclusion que je peux me contenter d'une table Question (QuestionID int, Question varchar (max)) et une table de réponse (ResponseID int, QuestionID int, UserID int, bit de réponse). – Joshua

Pour normalisent pleinement, vous voudrez peut-être envisager une structure comme celle-ci:

Table Questionaire(
    QuestionaireID... 
    QuestionaireName... 

Table Questions(
    QuestionaireID... 
    QuestionID... 
    QuestionName... 

Table Response(
    QuestionaireID... 
    ResponseID... 
    UserID... 

Table Answers(
    AnswerID... 
    ResponseID... 
    QuestionID... 
    Answer...

Cette offre fidélité de l'information plus, comme vous pouvez capturer des données en plusieurs dimensions - au niveau de la réponse, l'individu niveau de réponse, ainsi que l'anticipation des modifications apportées au système.

Source

2009-08-16 00:19:06

La table de réponse ne doit-elle pas être liée à QuestionID plutôt qu'à QuestionaireID? Si les liens de réponses à QuestionID, QuestionaireID est vraiment nécessaire? Est-ce que ResponseID répond à la clé primaire ou un lien vers la table de réponses? – Joshua

@Joshua merci, les réponses ne doivent pas pointer vers des questionnaires. –

Voulez-vous réutiliser des questions différentes questionaires?
Voulez-vous que les utilisateurs puissent prendre plus d'un questionaire?
Voulez-vous que ce soit autre chose que des réponses oui/non, comme un choix multiple?

Si oui à tous les trois, je le ferais comme ceci:

Tableau Questionaire (QuestionaireID, Nom, Description)

Questions tableau (QuestionID, Nom)

Tableau QuestionResponses (QuestionResponseID, QuestionID, ResponseText)

Table QuestionaireQuestions (QuestionaireID, QuestionID)

Tableau UserQuestionaire (UserQuestionaireID, QuestionaireID, UserID)

Tableau UserResponses (UserQuestionaireID, QuestionResponseID)

Maintenant, vous pouvez définir une liste de questions, les ajouter à un à plusieurs questionaires, ils peuvent avoir un certain nombre de réponses , et les utilisateurs peuvent enregistrer un questionnaire et les réponses qu'ils choisissent.

Source

2009-08-16 02:53:55 Eric

Il y a toujours un compromis entre la normalisation et le pragmatisme en SQL. Votre réponse est hautement normalisée et correspondrait aux trois exigences que vous avez décrites, mais elle est un peu exagérée dans ma situation. Mon utilisation est un utilisateur qui demande un service. Ils doivent divulguer oui/non à des questions telles que «êtes-vous un fumeur», etc. Il s'agit strictement d'une relation 1-1 entre l'application et la réponse et il doit y avoir une réponse pour chaque question. colonnes dans la table d'application. Après avoir examiné la réponse de Berry Tsakala, je suis arrivé à la conclusion mentionnée dans les commentaires. – Joshua

Existe-t-il un meilleur moyen de structurer une table SQL traitant des questionnaires d'utilisateur?

Répondre

Questions connexes