db design - sondage / questionnaire avec questions et réponses

Question

Je suis en train de travailler sur un assez simple système de sondage sur la droite maintenant. Le schéma de la base est simple: un Survey tableau, dans un un-à-plusieurs relation avec Question tableau, qui est dans un un-à-plusieurs, en relation avec l' Answer tableau et avec l' PossibleAnswers table.

Récemment, le client a réalisé qu'elle veut la capacité de montrer certaines questions posées uniquement aux personnes qui ont donné une réponse particulière à une question (par exemple. Achetez-vous des cigarettes? serait suivie par Ce qui est votre favori marque de cigarettes?, il n'y a pas de point de poser la seconde question à un non-fumeur).

Maintenant que j'ai commencé à me demander quelle serait la meilleure façon de mettre en œuvre cette conditionnel à des questions en termes de mon schéma de base de données? Si question A a 2 réponses possibles: A et B, et question B ne doit apparaître à l'utilisateur si la réponse a été A?

Edit: Ce que je cherche est un moyen de stocker ces informations sur les conditions requises dans une base de données. Le traitement des données sera probablement fait sur le côté application, comme mes compétences SQL sucer ;)

Answer 1

Enquête Sur La Conception De Base De Données

Si vous utilisez ce (haut) réponse ou n'importe quel élément, veuillez ajouter des commentaires sur les améliorations !!!

C'est un vrai classique, faite par des milliers de personnes. Ils semble toujours "assez simple" pour commencer mais pour être bon, il est en fait assez complexe. Pour ce faire dans les Rails je voudrais utiliser le modèle illustré dans le diagramme ci-après. Je suis sûr qu'il semble façon plus compliqué pour certains, mais une fois que vous avez construit une quelques de ces, au fil des ans, vous vous rendez compte que la plupart des décisions de conception très classique de motifs, de mieux traités par une dynamique flexible structure de données au départ.
Plus de détails ci-dessous:

Détails de Table pour les tables de clés

réponses

Les réponses de la table est essentiel car il capture les réponses apportées par les utilisateurs. Vous remarquerez que les réponses des liens vers question_options, pas de questions. Cela est intentionnel.

input_types

input_types sont les types de questions. Chaque question ne peut être que de type 1, par exemple, tous les la radio de cadrans, de tout champ de texte(s), etc. Utiliser des questions supplémentaires pour quand il y a des (dis) 5 radio-cadrans et 1 case pour une "inclure?" option ou quelque combinaison. Étiquette les deux questions dans la vue des utilisateurs comme l'un mais en interne, deux questions, l'une pour la radio-cadrans, l'un pour la case à cocher. La case à cocher permet à un groupe de 1 dans ce cas.

option_groups

option_groups et option_choices vous permettent de construire des "communes" des groupes. Un exemple, dans un logiciel immobilier il y a peut-être la question " quel est l'âge de la propriété?'. Les réponses peuvent être désirées dans les gammes: 1-5 6-10 10-25 25-100 100+

Alors, par exemple, s'il y a une question sur la propriété voisine de l'âge, l'enquête se veulent "réutiliser" au-dessus des plages, de sorte que même option_group et les options utilisées.

units_of_measure

units_of_measure est qu'il y paraît. Si c'est des pouces, des tasses, des pixels, des briques ou que ce soit, vous pouvez le définir une fois ici.

Pour info: Bien que de nature générique, on peut créer une application sur le dessus de cela, et ce schéma est bien adapté à la Ruby on Rails cadre d'autres conventions telles que "id" pour la clé primaire de chaque table. Aussi les relations sont toutes simples one_to_many est sans many_to_many ou has_many servitudes nécessaires. Je serais probablement ajouter has_many :through et/ou :les délégués de recevoir des choses comme survey_name d'un individu de répondre facilement sans.de multiples.le chaînage.

Answer 2

Vous pourriez aussi penser à des règles complexes, et ont une chaîne de caractères en fonction de la condition de champ dans vos Questions table, accepter/analyse de l'un de ces:

• Une(1)=3
• ( (Une(1)=3) et (A(2)=4) )
• Un(3)>2
• (A(3)=1) et (Une(17)!=2) et C(1)

Où A(x)=y signifie "Réponse de la question x est y" et " C(x) désigne l'état de la question x (par défaut true)...

Les questions ont un champ ordre, et vous allez parcourir un par un, sauter des questions où la condition est FAUSSE.

Cela devrait permettre à des enquêtes de toute la complexité que vous voulez, votre GUI pourrait créer automatiquement ces en "mode Simple" et de "mode Avancé", où l'utilisateur peut entrer dans les équations directement.

Answer 3

une solution consiste à ajouter un tableau 'exigences de la question' avec des champs:

• question_id (lien vers la question "Quelle marque?")
• required_question_id (lien vers la question "fumes-tu?")
• required_answer_id (lien vers la réponse "oui")

Dans l'application, vous consultez ce tableau avant de poser une certaine question. Avec une table séparée, il est facile d'ajouter des réponses obligatoires (ajouter une autre ligne pour la réponse "parfois", etc.).

Answer 4

Personnellement, dans ce cas, je voudrais utiliser la structure que vous avez décrit et utiliser la base de données comme un idiot mécanisme de stockage. Je suis fan de la mise de ces complexes et dependend contraintes dans la couche application.

Je pense que la seule façon de faire respecter ces contraintes sans construire de nouvelles tables pour chaque question avec les clés étrangères pour les autres, est d'utiliser le T-SQL truc ou d'un autre fournisseur de mécanismes spécifiques pour construire des déclencheurs de base de données pour faire respecter ces contraintes.

Au niveau de l'application que vous avez obtenu beaucoup plus de possibilités et il est plus facile de port, donc je préfère cette option.

J'espère que cela va vous aider à trouver une stratégie pour votre application.