Je sais que vous luttez avec beaucoup de choses en même temps, mais la meilleure réponse résout le problème que ikegami vite passé sur le point de le faire en Perl :
Les gens font souvent beaucoup plus que ce dont ils ont besoin au niveau de l'application car ils n'apprennent jamais à faire les bonnes choses dans la base de données (comme votre autre question auquel il vaut mieux répondre par une requête SQL appropriée au lieu de Perl). Mais, en aparté, beaucoup de gens font ça parce qu'ils sont incapables de changer le schéma. L'heuristique sociale, telle que l'application appropriée de la bière, facilite parfois ce chemin. Un peu de travail pour convaincre les gens de la base de données rapporte plusieurs fois plus tard. Et, comme autre aparté, le "développeur full stack" omet souvent toute utilisation sophistiquée des bases de données.
Je ne vais forcer personne à lire la Base de données en profondeur de C.J. Date , mais il y a beaucoup de valeur à obtenir le bon schéma. Par droit, je veux dire qu'il impose le moins d'efforts et de complexité à son utilisation. Les choses devraient être simples et vous ne devriez pas avoir à réorganiser ces éléments au niveau de l'application.
Vous voulez compter le nombre de fois où chaque réponse est sélectionnée. Compter est quelque chose que les bases de données font très bien, alors laissez la base de données le faire.
Vous avez des questions. Les questions ont diverses réponses. Les enquêtes regroupent des ensembles de questions. Les gens répondent aux sondages en associant leurs réponses aux questions.
Voici une conception de schéma simple (et un type de base de données finira par apparaître et me dira que je ne l'ai pas fait correctement, mais ça va). L'astuce est que rien ne doit avoir plusieurs colonnes inutilisées. Tout vient dans un petit paquet soigné (la "relation" dans "base de données relationnelle") qui est facilement connecté aux autres choses via des "clés étrangères" (par exemple, question_id pour mapper une réponse à la question). Les réponses, par exemple, auront plusieurs lignes pour le même question_id .
Si quelqu'un veut venir avec les outils de modélisation sophistiqués et faire l'image, allez-y. Je marque ceci comme wiki communautaire.
Table: Questions
id
text
Table: Answers
id
text
question_id
Table: Surveys
id
title
Table: SurveyQuestionSet
id
survey_id
question_id
Table: Respondent
id
text
Table: Response
id
respondent_id
survey_id
question_id
answer_id
Une fois cartographié et normalisé correctement (lisez les formulaires normaux ), il est très facile d'obtenir les données souhaitées avec les SELECT. L'idéal de normaliser est simplement de ne pas répéter l'information ou de lui permettre d'entrer dans un état incohérent. Dans ces formulaires, beaucoup de choses deviennent beaucoup plus faciles à faire.
Et, si vous voulez pratiquer de telles choses, le Stackoverflow Data Explorer est un ensemble de données réelles normalisé par rapport à ce que j'ai présenté ici.
Maintenant, vous comptez simplement le nombre de fois answer_id s'affiche pour une combinaison particulière d'enquête et de question. Utilisation astucieuse de GROUP BY fait tout le travail pour vous. Vous n'avez plus besoin de parcourir les lignes en regardant des dizaines de colonnes inutilisées en essayant de comprendre comment les compter. Non seulement cela, mais vous pouvez faire ces choses vues
, ce qui signifie que vous écrivez la requête une seule fois et que la base de données prétend que ses résultats sont une table. Vous pouvez alors simplement interroger la vue (donc tous les JOIN s et pareillement sont cachés), ce qui est très simple. Les procédures stockées sont également souvent négligées.
