Stocker et afficher des données de questionnaire, une solution plus facile?

Question

Fondamentalement, il s'agit d'un questionnaire, mais cela ne demande pas seulement le type de questions Oui/Non. Il y a des questions qui sont posées sous la forme d'un tableau. Voici un exemple de l'une des pages d'étape du questionnaire:

Le questionnaire permet à un client de sauvegarder ce qu'il a entré, de se déconnecter, de revenir plus tard et de continuer à remplir le reste, puis soumettre. Un administrateur examinera également le questionnaire et permettra au fournisseur d'accéder à seulement certaines des questions au cas où des corrections seraient nécessaires.

Le texte suivant décrit ma solution pour stocker les données, mais je me demandais s'il y avait une façon plus simple de le faire. Voici également le Database Design pour le tableau des questions et réponses, situé sur le côté droit de l'image.

Les noms de colonne pour la question doivent être stockées sous forme de questions distinctes aussi bien, sauf que maintenant par exemple des questions 4.a, aura

4.a.1, "Standard" 
4.a.2, "Certifying Organization" 
4.a.3, "Date of Last Certification" 

Donc, pour afficher ce serait assez simple. Si nous définissons le type de la question comme un nouveau type, par exemple TABLECOL, nous saurons créer une table et une colonne de table. "De plus, comme les données vont être extraites par ordre croissant, cela ne devrait pas poser de problème. De toute façon, je pense que nous serons bien avec toutes les cellules comme types de saisie de texte (peut-être dans le futur, si et quand le moment viendra, une des colonnes d'un tableau ne sera peut-être pas un texte champ d'entrée, il pourrait par exemple s'agir d'un menu déroulant, donc nous aurions besoin d'un moyen de décrire ce qu'il faut utiliser.)

Maintenant aussi lors de l'affichage de la table en html, la question 4.a a trois lignes par défaut. Les autres questions ont un numéro différent, je pensais aussi à la validation des colonnes de table, donc je pensais à la création d'une nouvelle table appelée QuestionAttributes, qui servira à stocker de nombreux attributs pour une question. ID de la Donc, un exemple de cette utilisation serait, la question 4.a est un tableau et devrait afficher 3 lignes. Dans la table d'attributs il y aurait une entrée telle que: idof 4.a, "MINROWS", 3

Pour stocker les données dans le tableau des réponses, nous devrions mettre un nouveau champ dans le tableau des réponses qui serait donnez la réponse à l'unicité et la capacité d'être aussi bien. Donc, au lieu d'utiliser une valeur d'auto-incrémentation, je dirais stocker l'horodatage UTC qui décrirait également quand la réponse a été donnée, le cas échéant. Cela permettra le tri pour nous aider à afficher les données dans le bon ordre dans le tableau de la page Web. Fondamentalement, dans le tableau des réponses, nous devrions avoir une valeur entière différente pour chaque réponse.

La requête pour récupérer les réponses doit avoir un tri sur la table Questions sort_order et la table Réponses utc_timestamp. Le résultat de cette requête ressemblera à quelque chose comme:

4.a.1, "Answer1", 9878921 
4.a.2, "Answer2", 9878923 
4.a.3, "Answer3", 9878925 
4.a.1, "Answer1", 9878926 
4.a.2, "Answer2", 9878928 
4.a.3, "Answer3", 9878929 

Toute aide serait grandement appréciée.

Answer 1

Vous allez probablement être en désaccord, mais je pense que le design est très surdimensionné, surtout pour une première version. Je partirais avec aussi simple design possible:

QuestionaireId 
Status   f.e. "Pre-Approval" 
StatusDate 
Answerer   f.e., "Mike Mayhem" 
Question1  f.e., "Yes" 
Question2  f.e., "Option6" 
Question3  f.e., "Blah Blah Blah" 
... 

Ensuite, vous pouvez avoir une table de journal qui dit quand quelqu'un a approuvé un article, a répondu à une question, et ainsi de suite:

LogId 
QuestionaireId 
LogDate 
LogEntry   f.e., "Questionaire approved by Bill" 

Pour nouvelles itérations après la première version, ajoutez des relations un-à-plusieurs ou plusieurs-à-plusieurs uniquement lorsqu'elles ajoutent une valeur commerciale énorme.Les relations sont coûteuses en termes de complexité, et la réduction de la complexité est l'essence même d'un bon design.