Bonjour,
 
Deux questions assez distinctes à propos de l'implémentation d'un système de questionnaire.
 
Niveau représentation des données en bases, je pars sur un truc très simple, à base d'une colonne par réponse. Concernant le type des champs, ENUM si supporté pour les questions à choix multiples, BOOL pour un oui / non, INTEGER pour une note sur 20...
 
J'ai vu quelques schémas où les données de réponses à un questionnaire données étaient disjointes dans plusieurs tables, mais je trouve ça bloaté (DatabaseAnswers 81 à 85 notamment).
 
C'est un cas somme toute basique, mais je me demande si je ne rate pas quelque chose.
 
La vraie question de ce topac est néanmoins le retraitement des données. Je sais qu'il existe des méthodes pour déterminer si un sondage (l'ensemble des réponses données par un "sondé" ) est pertinent, ou inversement invalider celui-ci, mais je ne trouve pas d'algo ni de ressources détaillant ces procédés. L'analyse statistique de ce type de données un métier à part entière bien évidemment, mais quelques filtres simples pourraient déjà améliorer la qualité générale du système.
 
Merci d'avance pour vos retours

Une colonne par réponse... si ton questionnaire est totalement figé à l'avance, que tu te moques de pouvoir exploiter les réponses fournies, et que tu te branles de respecter 30 ans de normes en sgbdr, pourquoi pas.
 
C'est le besoin qui dicte le modèle, alors on ne peut pas t'apporter une réponse avec le peu d'information que tu nous donnes.
Le nombre de question est il fixe, y a t-il plusieurs questionnaires, de quoi se compose une question et ses réponses, comment fige tu quelle était la bonne réponse, quels sont tes besoins en matière de statistiques... ?

Le questionnaire est figé, je saisi pas la remarque sur l'exploitation des données (du moins, je ne vois pas en quoi la solution à une réponse par colonne m'en empêcherais), et si le seul argument est "on fait comme ça depuis 30 ans" sans plus d'argumentation, oui, je vais avoir tendance à un peu m'en tamponner.

Nombre de question fixe (une vingtaine), questions à choix multiples avec un "Autre : préciser" pour certaines, questions avec notations sur 20, questions booléennes genre "satisfait / pas satisfait".

"comment fige tu quelle était la bonne réponse" => y'a pas de bonne ou mauvaise réponse, c'est une sorte de questionnaire de satisfaction.

Pour finir et rappeler ma seconde question, la plus importante et celle pourquoi je n'ai pas posté dans la cat SGBD, je ne retraite pas les données : le schéma que l'on évoque est pour du stockage embarqué, les différents enquêteurs déchargent ensuite leurs données, qui sont agrégées et renvoyées telle quelle vers un autre système. Sauf que, ma seconde question porte justement sur un éventuel retraitement "pré commit" si on peux dire, d'où ma recherche d'algos de pertinence des réponses à un questionnaire.

 
Je pense que tu veux dire une ligne par réponse, d'ou la réponse de TotalRecall: une colonne par réponse ca serait pas une bonne idée du tout (en fait, ca serait même impossible).
 

 
Ce n'est pas bloaté, la présence de plusieurs tables permet de faire du relationnel: si tu dois choisir parmis 150 destinations de voyage, par exemple, il est beaucoup plus interessant de mettre ces 150 destinations dans une table différente, avec chacune un identifiant; et de n'enregistrer que l'identifiant choisi pour chaque réponse. Ca à donc le meme effet qu'un ENUM, sauf que tu peux modifier les données (supprimer des destinations, en ajouter, corriger des fautes d'orthographe ... ) et partager cette table avec d'autres bouts de ton application (un autre sondage qui demande la destination peut aussi utiliser cette table, par exemple). Enfin, l'intéret le plus évident, c'est que tu peux avoir associé des infos spécifiques avec chaque élément(un prix et un pays pour chaque destination par exemple) et utiliser le lien dans un autre bout de l'appli (par exemple, donner le prix du trajet en fonction de la destination, une fois le sondage validé)
 
En gros, si la réponse est un choix entre < 10 éléments fixes, qui ne bougeront jamais (individuellement et en groupe) et ne sont liés à aucune autre donnée que leur "label"; tu peux utiliser un enum. Si toutes ces conditions ne sont pas remplies, il est préférable d'utiliser une table.
 

 
A priori, le "retraitement" des données dépend du type de données.  
 
Cependant, tu peux commencer par appliquer un poids à chaque champ suivant son importance pour le traitement et ne prendre en compte que les questionnaires dont le poids est suffisament important.  
Par exemple, je suis encore sur mon formulaire de choix de destination pour une agence de voyage.
Imaginons qu'il ait les champs: nom, prénom, mail, adresse, téléphone, destination préférée pour l'été, destination préférée pour l'hiver, connaissez vous l'agence, comment connaissez vous l'agence.
 
Si je cherche à prospecter des clients interessés, je met des poids sur les infos de contact (si non rempli, la valeur du champ*poids = 0, sinon = poids) et je ne prend que ceux qui ont rempli au moins 3 champs, par exemple.
Maintenant, si je cherche à savoir comment est perçue l'agence, je mettrai les poids sur la partie commentaire.
 
Si tu as plusieurs champs avec des notations, par exemple le retour d'un client sur un service, tu peux également utiliser ces poids pour déterminer si l'impression générale est plutot positive ou négative (en multipliant chaque note par le poids associé), puis en n'effectuant l'analyse que sur les types de réponses qui t'interessent (connaitre ce qui ne va vraiment pas => analyse sur les impressions négatives).
 
En règle générale, il ne sert à rien de "refuser" une réponse. Il est plus utile de mettre en place les règles de filtrage au moment de l'analyse des données. En effet, il est plus grave d'écarter des réponses dont on ne voit pas l'intérêt immédiatement que d'utiliser un peu de puissance de calcul au moment de la récupération des résultats. Ne serait-ce que parce que cela permet d'obtenir plusieurs grilles de lectures et analyse sur le même sondage et de les affiner en fonction des besoins (si un filtre est trop restrictif ou pas assez, il faut pouvoir le corriger, et ce n'est pas faisable avant d'avoir eu plusieurs réponses). Imagine si tu t'aperçois après coup qu'un champ que tu considérais très important pour considérer la réponse sérieuse n'est pas remplissable à cause d'un bug: toutes les réponses entrées jusque là et écartées par erreur sont perdues et les gens ne viendront jamais les remettre.
 
Enfin, il faut que le sondage soit représentatif: après filtrage, affiche toujours le nombre de résultats avant d'afficher les statistiques. Au dessous d'un nombre minimum de réponses, le sondage n'est plus représentatif. Je ne connais pas les valeurs exactes et cela dépend du groupe sondé mais typiquement les sondages INSEE se font sur 1000 personnes et sont très représentatif (bon c'est 1000 personnes en respectant en gros la répartition par age, métier ... représentatifs de la population francaise).

 
Non, j'entendais bien une ligne par sondé.
 
Exemple de sondage bidon :
 

 
Dans ma table, j'aurais outre l'id de la réponse (id de la série de réponses du sondé donc), un champ integer, un type enum, un type string nullable pour le "Autre (précisez)" et un booleen. Pendant le sondage, les réponses sont conservées en mémoire, on écrit en base à la clôture du sondage.
 
Alors oui, c'est pas extensible et le requettage est chiant, mais le questionnaire ne bougera pas et l'analyse est faite par un autre système, qui récupérera les données brutes agrégées.
 
Ça veut pas dire que je ne vais pas faire un truc un tant soit peu maintenable et évolutif (et donc un schéma plus riche), mais la question théorique reste posée, dans le sens où je ne vois pas trop l'intérêt si mon sondage est fixe et destiné à l'export uniquement.
 

 
Il y a des choses très intéressantes dans ta réponse, mais arrête-moi on parle bien d'analyse des résultats dans ce cas ? Ce que je recherche, c'est de la détection de "mauvais sondage", i.e. quelqu'un qui est saoulé de répondre et qui dit oui à tout, ou la première réponse à toute les questions, ou une réponse au pif à chaque fois... Je pourrais me cantonner à détecter ces cas de figure, mais je me suis dit qu'il devait y avoir de l'existant à ce sujet.
 
Lecture instructive dans tous les cas
 

 
Oui, c'est bien ce que j'entendais. Une ligne par sondé et en colonne les questions posées.
 

 
Je ne sais pas s'il existe des méthodes fiables pour détecter ce type de réponse. A priori une personne qui répond toujours oui à un QCM peut très bien le faire sans avoir baclé sa réponse. Ou alors tu détecte des combinaisons non valides, mais ça dépend de ton sondage ...
Sur les champs textes, il y a possibilité de détecter une entrée type "dgqsg", qui indique clairement que la réponse est baclée. Si tu as accés au web, tu peux utiliser l'API Google language  
http://www.google.com/uds/samples/language/detect.html  
http://code.google.com/apis/ajax/p [...] age_detect
Elle intègre un score de confiance, qui indique sa certitude que le texte est bien de la langue donnée. Ce score grimpe difficilement sur les petits textes, cependant (pas assez de contenu...)
 
Tu peux enfin utiliser un dictionnaire avec les termes courants en français: verbes être et avoir conjongués, conjonctions, pronoms ... et repérer leur présence dans le texte, tout en tenant compte de sa taille (un texte < 10 caractères peut il constituer une réponse suffisante ? a l'inverse, un texte de 150 caractères avec juste "a" de reconnu est il valable ?)
L'avantage c'est que c'est une solution facile à mettree en place et peu couteuse.
 
Encore moins couteuse, tu peux effectuer une analyse fréquentielle à la main: tu comptes la quantité de chaque type de lettre et en fonction du résultat tu pourra en déterminer si le texte possède un sens ou est juste du bruit (par exemple, nombre de e; nombre de voyelles/nombre de consonnes; 5 premières lettres présentes ...)
http://fr.wikipedia.org/wiki/Analy [...] quentielle